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ABSTRACT 


Historically,  military  technical  control  facilities  (TCF) 
have  performed  their  supervisory  and  control  functions  over 
communications-electronics  systems  by  manual  processes,  using 
verbal  and/or  teletype  conversations  for  coordinating  with 
distant  stations.  These  methods  will  soon  be  changed  with 
the  application  of  computers  to  automate  many  of  the  manual 
tasks  and  assist  the  technical  controllers  in  others.  One 
of  these  manual  tasks,  that  of  record-keeping  and  report 
generation,  promises  to  yield  significant  manpower  savings 
but  has  been  deferred  from  implementation  due  to  high  cost 
and  technical  complexity.  Accordingly,  this  thesis  proposes 
a  representative  software  program  for  an  automatic  report 
generator  using  the  Rand  Corporation  developed  production 
rule  system,  Rule-directed  Interactive  Transaction  Agent 
(RITA) .  It  facilitates  the  automatic  entry  of  data  into 
reporting  formats,  automatic  generation  of  data  into  files/ 
reports,  a  capability  to  alter  report  formats  and  file 
building  rules,  and  algorithms  for  automated  statistical 
analysis  of  data  files. 
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I .  INTRODUCTION 


The  author  was  assigned,  for  a  two  year  period  in  the 
early  1970's,  as  commander  of  a  major  communications  facility 
in  the  mountains  of  southern  Italy.  Mt.  Vergine  is  a  pri¬ 
mary  nodal  point  in  the  wideband  radio  transmission  network 
of  the  Defense  Communications  System  (DCS)  in  Europe.  Its 
mission  is  to  provide  DCS  connectivity  to  US  forces  located 
in  the  Mediterranean  area,  including  Italy,  Greece,  and 
Turkey . 

The  major  communications-electronics  facilities  at  the 
station  are  an  AUTOVON  switching  center,  several  microwave 
and  tropospheric  scatter  radio  equipments,  and  a  primary 
technical  control  facility  (TCF) .  Essentially  the  heart 
of  the  station,  the  TCF  function  alone  required  in  excess 
of  30  military  personnel. 

During  this  two  year  period,  many  preparations  were 
underway  (including  construction  of  a  new  building)  in 
anticipation  of  a  major  TCF  upgrade  program,  the  World- 
Wide  Technical  Control  Improvement  Program  (WWTCIP) . 
Unfortunately,  the  program  never  reached  fruition  due  to 
technical  difficulties  and  contractor  default. 

A  companion  TCF  improvement  effort,  however,  is  still 
viable  and  promises  significant  benefits.  The  Automated 
Technical  Control  (ATEC)  program  is  developing  computer- 
assisted  equipments  and  procedures  for  the  TCF  function. 


7 


The  ATEC  benefits  of  improved  customer  service,  coupled 
with  an  accompanying  net  savings  in  manpower,  certainly  has 
raised  the  interest  of  the  military  services. 

The  interest  of  the  author  has  also  been  raised, 
especially  by  the  prospects  for  going  even  further  than 
the  current  effort  of  the  ATEC  program.  This  thesis  inves¬ 
tigates  further  ATEC  refinements,  which  would  yield  equally 
desirable  benefits  as  the  current  program.  The  aim  of  the 
thesis  is  to  illustrate  a  methodology  for  implementing  these 
refinements  and  to  motivate  their  eventual  incorporation 
into  the  ATEC  program. 
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II.  BACKGROUND 


Growing  weary  of  complaints  from  military  communications 
customers,  US  Air  Force  communications  planners  launched 
an  effort  in  the  late  1960 's  to  diagnose  system  degradation 
and  to  subsequently  remedy  that  degradation  before  system 
failure,  and  even  before  customer  detection  and  complaint. 

The  underlying  concept  was  tabbed,  "performance  assessment", 
and  was  directed  towards  detection,  isolation,  and  correction 
of  anomaly  conditions. 

Simultaneously  with  this  effort,  the  Air  Force  also  pro¬ 
posed  investigation  into  a  methodology  for  automating  selected 
portions  of  the  technical  control  functions  which  support 
the  DCS.  The  intent  of  this  effort  was  not  only  to  assist 
in  identifying  anomaly  conditions,  but  also  to  facilitate 
rapid  access  to  information  on  the  health  of  the  DCS  and  to 
reduce  manual  workload. 

For  nearly  ten  years,  several  feasibility  and  develop¬ 
ment  contractual  actions  have  been  pursued,  preparatory  to 
the  recent  contract  award  to  Ford  Aerospace  and  Communications 
Corporation  for  the  ATEC  program.  The  design  of  the  ATEC 
equipment,  however,  does  not  focus  upon  the  reduction  of 
manpower  as  a  principal  objective.  Rather  its  concepts  are 
directed  more  towards  the  automation  of  routine,  repetitive, 
scheduled  tasks  so  as  to  shift  management ’ s  attention  from 
diagnostic  to  remedial  actions.  An  incidental  benefit  of 
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the  ATEC  program  is  the  expected  net  tri-service  manpower 
reduction  of  117  authorizations  in  technical  control  and 
wideband  test  teams  [2] . 

Air  Force  communications  planners  are  now  pursuing  the 
feasibility  and  associated  benefits  of  certain  unscheduled 
(and  other  scheduled)  tasks  with  an  eye  towards  realizing 
further  manpower  savings.  There  appears  to  be  three  classes 
of  technical  control  workload  which  offer  the  greatest 
opportunity  for  further  manpower  reductions.  These  classes 
of  workload  are  coordination,  record-keeping,  and  reporting, 
each  of  which  depends  upon  the  effective  functioning  of  an 
"information-flow  management  system". 

The  automation  of  reporting  and  record-keeping  offers 
the  most  significant  manpower  savings,  an  additional  106 
tri-service  authorizations.  The  necessary  functions  that 
would  be  required  of  ATEC  in  order  to  realize  these  addi¬ 
tional  savings  are  [2]  : 

1.  defining/generating  files  automatically  according 
to  established  or  changed  criteria. 

2.  generating/altering  rules  or  criteria  for  building 
of  data  files, 

3.  generating/altering  report  formats,  and 

4.  assigning  rules,  criteria,  or  mathematical  opera¬ 
tions  on  stored  data  for  preformatted  reports. 

These  functions  are  the  core  of  a  proposed  automatic 
report  generation  enhancement  to  the  original  ATEC  specifi¬ 
cations.  Unfortunately,  this  particular  enhancement  has 
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been  categorized  by  the  ATEC  System  Project  Office  as  too 
costly  (over  $2  million)  and  too  complex  (beyond  the  capa¬ 
bility  of  station  processor  architecture)  to  be  incorporated 
into  the  ATEC  program.  This  enhancement  is  apparently 
relegated  to  a  deferred  status  for  follow-on  analysis  [2] . 

It  appears  that  presently  on-going  research  and  develop¬ 
ment  efforts  in  the  computer  science  industry,  such  as 
microprocessor  technology,  artificial  intelligence,  and 
management  information  systems,  can  satisfy  the  processing 
requirements  of  the  automatic  report  generation  enhancement 
in  the  future.  The  potential  realization  of  the  enhancement, 
therefore,  provides  the  motivation  for  this  thesis  in  inves¬ 
tigating  the  applicabilitv  of  the  Rand  Corporation  developed 
RITA  language. 

RITA  is  a  language  which  allows  the  user,  even  a  "computer 
non-sophisticate",  to  interact  with  a  computer  using  very 
English-like  commands.  It  has  only  one  control  structure, 
referred  to  as  production  rules,  of  the  form  predicate  - 
action  (if  -  then)  rules  operating  on  a  data  base  under 
the  control  of  a  rule  interpreter/monitor.  RITA  appears 
to  be  an  ideal  candidate  language  for  implementing  the  ATEC 
automatic  report  generation  enhancement. 

The  next  chapter  explains  the  nature  of  the  DCS , 
focusing  on  the  requirement  for  automating  its  technical 
control  functions . 
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III.  DEFENSE  COMMUNICATIONS  SYSTEM  (DCS) 


Prior  to  developing  a  representative  software  package 
for  automating  the  technical  control  functions  of  the  DCS, 
it  is  necessary  to  have  an  understanding  of  the  DCS  and 
its  inner-workings,  component  parts,  and  management  struc¬ 
ture.  Thus,  this  chapter  presents  the  essential  features 
of  the  DCS  and  concludes  with  explaining  the  role  of  system 
control  [3] . 

A.  GENERAL 

The  DCS  is  the  worldwide  complex  comprised  of  long-haul, 
point-to-point  communications  facilities,  personnel,  and 
material  within  the  Department  of  Defense.  The  DCS  includes 
land,  sea,  and  airborne  communications  required  to  connect 
the  primary  and  alternate  fixed  or  mobile  command  posts 
of  the  President,  the  Secretary  of  Defense,  the  Joint  Chiefs 
of  Staff,  and  Unified/Specified  Commanders. 

The  DCS  embraces  all  long-distance  point-to-point  assets 
of  the  three  military  departments.  It  includes  circuitry 
by  radio  (microwave,  tropospheric  scatter,  and  high  frequency) , 
wire,  submarine  cable,  and  satellite  from  any  fixed  location 
to  any  other  fixed  location.  Excluded  from  the  DCS  are  the 
tactical  communications  systems  operated  by  field  commanders. 
Examples  are  the  Navy's  fleet  broadcast  and  ship-to-shore 
circuits,  ground-to-air  communications  of  the  Air  Force,  and 
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tactical  communications  of  the  Army  between  field  units 
where  mobile  type  equipment  is  used. 

B.  FUNCTIONAL  RELATIONSHIPS 

The  Director,  Defense  Communications  Agency  (DCA)  is 
responsible  to  ensure  that  the  DCS  is  planned,  engineered, 
and  operated  to  meet  the  long-distance  requirements  of  the 
DoD  and  other  governmental  agencies.  To  accomplish  this, 

DCA  performs  the  planning,  programming,  management  control 
and  operational  direction  for  the  DCS. 

Operational  direction  is  the  authority  to  ensure  effec¬ 
tive  operation  of  the  DCS,  including  directing  the  operating 
elements,  reallocating  DCS  operational  facilities  to  accom¬ 
plish  DCA 1 s  mission,  prescribing  standards  and  procedures, 
and  analyzing  system  performance  and  operation  of  the  DCS. 

This  operational  direction  is  applied  either  directly  to 
DCS  TCFs ,  DCS  switching  or  satellite  facilities,  or  through 
the  appropriate  management  level  of  the  military  services. 

The  DCA  Operations  Control  Complex  is  the  principle  agent 
for  exercising  operational  direction,  consisting  of  13 
operations  centers  throughout  the  world. 

The  military  departments  are  responsible  for  the  opera¬ 
tion  and  maintenance  (O&M)  of  DCS  components  under  their 
management  supervision.  Primarily,  the  Army  Strategic  Com¬ 
munications  Command,  The  Naval  Telecommunications  Command, 
and  the  Air  Force  Communications  Service  (called  O&M  Managers) 
carry  out  these  responsibilities  through  subordinate  units 
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which  they  command  or  operationally  control.  These  latter 
units  are  generally  referred  to  as  operating  elements  of 
the  DCS.  The  O&M  Managers  are  also  responsible  for  the 
budgeting,  acquisition,  installation,  and  personnel  training 
aspects  in  support  of  the  DCS,  including  leased  facilities. 

C.  SWITCHED  NETWORKS  AND  SUBSYSTEMS 

The  Automatic  Voice  Network  (AUTOVON)  is  the  principal 
long-distance,  unsecure  voice  communications  network  within 
the  DCS.  It  accommodates  voice  requirements  for  essential 
command  and  control,  operations,  intelligence,  logistic, 
diplomatic,  and  administrative  traffic .  AUTOVON  also  pro¬ 
vides  the  interconnection  of  subscribers  in  the  Automatic 
Secure  Voice  Communications  (AUTOSEVOCOM)  Network  and  a 
means  for  restoration  of  Automatic  Digital  Network  (AUTODIN) 
trunks . 

The  AUTOSEVOCOM  provides  secure  voice  service  to  nearly 
1900  special  users  by  means  of  several  types  of  switches 
with  automatic,  semi-automatic,  and  manual  interfaces  to 
terminal  instruments . 

The  AUTODIN  functions  as  a  high-speed,  computer-controlled 
general  purpose  record  communications  network.  It  is  an 
integrated,  world-wide  network  which  provides  both  secure 
and  non-secure  data  communications.  It  consists  of  leased 
and  government -owned  Automatic  Switching  Centers  with  con¬ 
necting  interswitch  trunks. 

The  Defense  Special  Security  Communications  System 
(DSSCS)  provides  for  exchange  of  intelligence  information 


and  other  record  communications  which  require  specialized 
security  procedures.  However,  much  of  this  traffic  is  to 
be  satisfied  by  the  AUTODIN  II,  thereby  negating  the  need 
for  separate  switched  networks  in  the  future. 

Dedicated  networks  and  circuits  are  decreasing  in  number 
as  more  of  them  are  being  integrated  into  the  switched  sub¬ 
systems  and  networks. 

D.  TRANSMISSION  SUBSYSTEMS 

Government-owned  submarine  cable  subsystems  include 
those  serving  Greenland/Newfoundland,  Alaska,  Hawaii/ 
Johnston  Island,  and  the  Philippine  Islands.  Most  of  the 
government-owned  DCS  landline  cable  is  in  Alaska.  Other 
DCS  landline  cables  are  located  in  Germany  and  in  the 
Orient. 

High  frequency  (HF)  radio  operations  are  being  phased 
down  but  still  provide  the  primary  means  of  communications 
in  certain  areas  of  the  world  where  there  is  no  other  DCS 
media  and  where  commercial  systems  do  not  provide  the  requi¬ 
site  quality.  Areas  still  being  served  by  HF  include  the 
Azores,  Iran,  Saudi  Arabia,  and  Antarctica.  Further,  HF  is 
often  used  as  a  secondary  means  of  communications  in  certain 
parts  of  the  world. 

Broadband  transmission  media  is  the  workhorse  of  the 
present  DCS.  Tropospheric  scatter  radio,  microwave  radio, 
and  other  line-of-sight  radios  comprise  subsystems  that  pro¬ 
vide  communications  to  US  government  facilities  outside  the 


continental  United  States  (CONUS) .  Microwave  radio  normally 
provides  the  most  reliable  communications.  However,  micro- 
wave  requires  repeater  stations  spaced  relatively  close 
together  which  often  presents  the  problem  of  obtaining  host 
country  land  rights.  Tropospheric  scatter  radio  fills  this 
gap  by  being  able  to  cover  distances  up  to  500  miles  with 
quality  communications.  Major  concentrations  of  broadband 
media  are  in  Europe,  as  well  as  much  of  the  rest  of  the  world 

The  Defense  Satellite  Communications  System  (DSCS)  con¬ 
sists  of  a  complex  of  synchronous  satellites  which  provide 
nearly  total  earth  coverage  with  highly  reliable  communi¬ 
cations  to  fulfill  unique  and  vital  national  security  needs. 
In  addition  to  fixed  ground  terminals  around  the  world,  this 
system  provides  for  highly  transportable  ground,  shipboard, 
and  airborne  terminals. 

DCS  communications  within  the  CONUS  is  provided  almost 
exclusively  by  leased  commercial  communications  because  of 
economic  policy  and  the  high  reliability  of  the  service 
offered.  For  transoceanic  service,  the  DCS  relies  heavily 
upon  leased  commercial  submarine  cable  and  satellite  cir¬ 
cuitry.  In  overseas  areas,  leased  commercial  communications 
are  used  when  they  provide  the  quality  required  and  they 
can  be  obtained  at  reasonable  costs.  Currently,  overseas 
leased  commercial  communications  are  used  primarily  to 
supplement  the  government -owned  transmission  media. 


E.  SYSTEM  CONTROL  (SYSCON) 

The  DCS  System  Control  (SYSCON)  incorporates  all  the 
means  for  utilizing  DCS  assets  to  insure  the  optimum  DCS 
performance  under  all  operating  conditions.  The  operating 
conditions  include  such  vagaries  to  the  system  as  changing 
traffic  demands,  natural  or  man-made  stresses,  environmental 
disturbances,  and  equipment  disruptions.  SYSCON  is  effected 
through  such  functional  elements  as  network  control,  traffic 
and  routing  control,  performance  assessment,  status  monitoring, 
and  technical  control.  These  functional  elements  are  realized 
through  the  SYSCON  processes  of  timely  acquisition  of  per¬ 
formance  data,  traffic  loading  status  and  service  quality 
indications  and  the  rapid  analysis,  processing  and  display 
of  this  information  along  with  effective  execution  of  control. 

There  are  five  hierarchical  levels  of  organizational 
structure  associated  with  DCS  SYSCON.  Execution  of  restoral 
and  reconfiguration  actions  is  accomplished  at  the  lowest 
levels  while  analysis  and  reporting  are  performed  at  the 
higher  levels.  The  relationships  between  the  various  SYSCON 
levels  is  especially  controlled  to  enhance  DCS  connectivity, 
quality  and  survivability  as  well  as  to  assure  management 
visibility.  Figure  1  depicts  the  five  level  hierarchy,  along 
with  the  level  names  and  functional  scope  of  authority  [4], 

The  TCF  is  an  organic  part  of  a  DCS  station  located  at 
a  major  transmission  node  that  serves  as  the  point  of  inter¬ 
face  between  transmission  elements  of  the  DCS  and  the  users. 
Technical  control  includes  the  functions  of  technical  direction 
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coordination,  communications  service  restoration,  fault 
isolation,  quality  control,  and  status  reporting.  A  TCF 
is  configured  so  as  to  enable  the  technical  controller  to 
fully  apply  the  available  DCS  resources.  This  capability 
requires  a  responsive  orderwire  and  control  network  between 
various  elements  of  the  DCS. 

A  TCF  is  often  assigned  additional  SYSCON  responsibili¬ 
ties  if  it  also  must  function  as  an  Intermediate  Control 
Office  or  Facility  Control  Office.  These  responsibilities 
involve  a  broadened  scope  of  data  collection/analysis, 
record-keeping,  coordination  with  affected  facilities,  and 
technical  management  in  general. 

The  tasks  of  reporting  and  record-keeping  might  appear 
to  be  a  rather  straight-forward  matter,  but  upon  further 
investigation  several  interesting  characteristics  are 
observed.  Both  tasks  are  essentially  manual  procedures. 

The  first  deals  with  apprising  higher  echelons  of  status 
information,  the  second  with  locally  documenting  the  status 
on  logs  and  forms.  Excessive  time  (up  to  26%  of  direct 
workload  hours)  is  spent  in  reporting,  logging  and  record¬ 
keeping.  Substantial  information  is  often  not  recorded 
because  of  other  pressing  workload  or  merely  the  manual 
effort  involved.  Reporting  criteria  can  be  interpreted 
differently  by  TCFs,  causing  inconsistencies  in  report 
information.  Reports  are  often  received  by  higher  echelons 
too  late  to  enable  the  taking  of  effective  actions  [2] . 
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IV.  AUTOMATED  TECHNICAL  CONTROL  (ATEC)  PROGRAM 


The  automation  of  selected  technical  control  functions 
is  now  underway.  This  chapter  describes  that  automation 
effort,  highlighting  the  need  to  also  include  the  tasks 
of  record-keeping  and  report  generation. 

A.  BACKGROUND 

The  increasingly  complex  mission  of  the  DoD  dictates 
ever  stringent  requirements  for  highly  reliable,  responsive 
communications  services.  Unfortunately,  the  operating  ele¬ 
ments  of  the  DCS  have  not  kept  pace  with  the  requirements. 

As  a  result,  the  DCS  is  too  often  subjected  to  unscheduled 
outages  and  degraded  customer  service.  A  goodly  portion  of 
the  blame  for  this  situation  falls  to  an  inadequate  tech¬ 
nical  control  function. 

Present  TCF  procedures  and  capabilities  are  insufficient 
to  provide  the  functions  of  effective  control  and  direction 
of  communications  services.  Too  often  customer  service 
receives  the  requisite  quality  control  monitoring  only  after 
a  customer  complaint  is  lodged.  The  TCF  needs  to  redirect 
its  attention  towards,  and  be  provided  the  tools  to  realize, 
a  level  of  technical  control  that  detects  system  degrada¬ 
tions  before  they  adversely  affect  system  performance. 

Thus,  the  concept  of  an  ATEC  program  was  developed  -  to 
provide  an  automated  capability  that  would  relieve  selected 
labor-intensive  functions  performed  within  the  DCS  SYSCON. 
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Specifically,  ATEC  will  provide  automation  of  many  of  the 
manual  technical  control  functions. 

B .  ATEC  SYSTEM 

The  ATEC  system  will  consist  of  those  equipments,  per¬ 
sonnel,  and  operating  procedures  necessary  to  provide  a 
computer  assisted  capability  for  accomplishing  many  of  the 
transmission  and  network  control  functions  of  the  DCS. 

ATEC  will  address  the  processes  of  circuit  and  transmission 
system  performance  assessment,  equipment  status  monitoring, 
fault  isolation,  quality  control,  centralized  sector  and 
nodal  system  status  display,  routing  plans  and  record 
storage,  and  report  preparation. 

The  ATEC  subsystems  will  parallel  the  DCS  SYSCON  levels 
as  shown  in  figure  1.  Operational  direction  and  control 
actions  generally  flow  downward  in  the  hierarchical  struc¬ 
ture  while  reports  flow  upward.  The  organizational  levels 
of  the  DCS  and  ATEC  correspond  approximately  to  geographic 
boundaries,  with  several  DCS  stations  being  controlled  by 
a  nodal  control  and  several  nodal  control  points  by  a  sector 
control.  The  ATEC  components  will  be  superimposed  over  the 
DCS  according  to  the  configuration  requirements  of  each 
facility,  properly  sized  and  interconnected.  Only  the  sec¬ 
tors,  nodes,  and  stations  will  receive  ATEC  components  which 
will  normally  operate  as  a  system;  nodal  and  station  con¬ 
trols  will  have  a  degraded  mode  capability  to  operate  as 
stand-alone  facilities  in  the  event  of  failure  of  interconnec¬ 
tions  [3]  . 
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The  overall  resultant  of  implementing  the  ATEC  system 
is  expected  to  be  improved  effectiveness  and  efficiency  in 
the  management  and  technical  control  of  the  DCS.  As  such, 

ATEC  will  become  a  subset  of  DCS  SYSCON,  satisfying  the 
requirements  of  transmission  control  and  performance 
assessment.  In  fact,  ATEC  will  be  a  prime  contributor  to 
the  DCA's  efforts  in  developing  an  integrated,  automated 
SYSCON  capability  to  manage  the  entire  DCS. 

The  process  of  acquiring  an  ATEC  system  was  initiated 
in  the  late  1960's  by  the  US  Air  Force,  sponsored  by  DCA. 

Early  efforts  began  with  a  research,  development,  test,  and 
evaluation  program  to  develop  specialized  test  equipment, 
computer  memory  and  processing,  and  various  software 
algorithms.  In  the  mid-1970's,  the  procurement  approach 
was  revised  from  using  design  specifications  to  functional 
performance  specifications.  This  latter  action  was  taken 
to  achieve  a  more  competitive  procurement  and  reduced 
acquisition  costs,  as  well  as  take  advantage  of  technical 
developments,  especially  for  greater  modularity  and  flexibility. 

Since  changing  to  a  functionally  oriented  test  program, 
test  and  evaluation  efforts  have  been  intensified.  A  joint 
test  team  was  organized  to  evaluate  the  performance  of  a 
test  bed  system  that  had  been  established  in  Europe.  Pre¬ 
liminary  test  data  indicated  questionable  benefits  of  man¬ 
power  savings  and  improved  DCS  performance.  A  subsequent 
cost  benefits  analysis  of  the  ATEC  program  has  vindicated 
the  acquisition  program. 
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The  major  conclusion  of  the  cost  benefits  analysis  is 
the  significant  manpower  savings  associated  with  the  ATEC 
program.  As  presently  envisioned,  ATEC  would  facilitate 
a  30%  reduction  in  TCF  manning.  After  allowing  for  manpower 
increases  to  support  the  ATEC  system  itself,  manpower  savings 
would  amount  to  approximately  89  authorizations.  Because 
of  improved  performance  assessment,  it  is  expected  that  28 
manpower  spaces  could  be  eliminated  from  the  current  force 
of  DCA  wideband  evaluation  teams.  Thus,  net  tri-service 
manpower  reductions  are  estimated  conservatively  at  117 
billets  [ 2 ] . 

The  other  benefits  of  the  ATEC  program  also  support 
continuation  of  the  acquisition.  ATEC  is  the  basis  for 
the  automated  DCS  SYSCON  and  is  endorsed  by  the  DCS  Five 
Year  Program,  FY  1980-1984.  There  is  no  viable  alternative 
to  ATEC  currently  under  consideration.  Because  of  its 
modular  nature  for  implementation,  ATEC  will  be  able  to 
accommodate  even  those  significant  portions  of  the  DCS 
which  are  non-standardized  as  well  as  those  of  an  evolving 
digital  DCS. 

The  acquisition  of  ATEC  will  attempt  a  phased  procure¬ 
ment  and  delivery  of  components.  A  request  for  proposal 
and  functional  specifications  for  a  Low  Rate  Initial  Pro¬ 
duction  (LRIP)  system  were  released  to  industry.  Ford  Aero¬ 
space  and  Communications  Corporation  (FACC)  has  been  awarded 
the  contract  for  these  LRIP  components  and  has  developed 
their  technical  proposal  to  an  extensive  degree. 
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Subject  to  final  System  Design  Review,  FACC  tentatively 
proposes  to  produce  applications  programs  written  in  a  single 
higher  order  language  (HOL) ,  FORTRAN  IV-PLUS.  The  use  of 
MACRO-11  assembly  language  will  be  restricted  to  those  pro¬ 
grams  where  using  a  HOL  would  not  be  efficient  or  practical. 
The  Digital  Equipment  Corporation  will  be  the  pA  ne  equip¬ 
ment  source  for  PDP-11/70  minicomputers  (512  kbit  memory) 
for  sector  and  nodal  levels  and  LSI-11/2  microprocessor 
hardware  for  station  levels.  The  RSX-11M  operating  system 
and  the  CODASYL  DBMS-11  data  base  management  system  will  be 
used.  The  operator  query  capability  for  examining  the  data 
base  will  be  accomplished  using  a  FACC  provided  language 
called  QUERY  [7]. 

C.  RECORD-KEEPING  AND  REPORTS 

The  ATEC  baseline  requirements  include  the  need  for  pro¬ 
viding  computer  assistance  in  report  preparation  and  local 
record-keeping.  This  computer  assistance  is  to  be  used 
for  displaying  a  variety  of  different  fixed  report  formats 
to  the  controller,  for  allowing  the  entry  by  either  machine 
or  controller  of  address  information  and  data  items  into 
the  report  formats  and  for  automatically  transmitting  and 
obtaining  hard  copy  of  completed  reports. 

The  ATEC  man-machine  communications  interface  is  to 
allow  the  use  of  conventional  technical  control  terminology, 
units,  and  mnemonics  for  entry  of  information  and  receipt 
of  response.  The  machine  should  complete  or  acknowledge 
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requests  for  information  or  message  delivery  from  the 
operator  in  a  timely  manner. 

Messages  and  reports  between  controller  terminals  will 
be  preformatted  to  the  greatest  extent  possible,  with  unique 
identifiers  for  originating  station,  date-time  group,  and 
other  pertinent  information  to  identify  the  message  content. 
Controllers  will  be  able  to  send  multiple  address  messages 
simultaneously  to  receiving  destinations  [3] . 

While  it  would  appear  that  the  above  descriptions  are 
adequate  for  specifying  the  needed  function  of  record¬ 
keeping  and  report  generation,  the  LRIP  specifications  do 
not  sufficiently  address  the  requirement.  The  contractually 
binding  portions  of  the  specifications  are  unclear  and  leave 
much  of  the  requirement  open  to  interpretation  [2] . 

Further,  the  original  emphasis  of  the  ATEC  program  was 
towards  the  automation  of  routine,  repetitive  tasks  which 
would  directly  sustain  DCS  high  quality  performance.  Reduc¬ 
tion  in  TCF  manning  was  only  a  secondary  benefit.  There 
is  now  a  high  level  of  interest  at  Hq  Air  Force  Communica¬ 
tions  Service  (AFCS)  in  potential  manpower  reductions  resulting 
from  ATEC,  to  the  degree  that  a  significant  effort  is  under¬ 
way  there  to  append  the  original  LRIP  specifications  with 
proposed  enhancements  to  strengthen  and  more  fully  define 
them  [2] . 

The  enhancement  related  to  automatic  report  generation 
has  been  evaluated  by  the  ATEC  System  Project  Office  and 
determined  to  be  both  too  costly  and  complex  for  inclusion 
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with  the  LRIP  specifications.  Unfortunately,  this  enhance¬ 
ment  would  have  yielded  an  additional  manpower  savings  of 
106  authorizations.  Needless  to  say,  the  communications 
planners  are  quite  frustrated  with  the  prospect  of  this 
enhancement  being  merely  deferred  for  future  follow-on 
analysis  [2]. 

D.  AUTOMATIC  REPORT  GENERATION  ENHANCEMENT 

The  enhancement  provides  for  technical  controllers  at 
sectors,  nodes,  and  stations  having  the  capability  to 
specify  existing  ATEC  data  to  be  collected,  to  specify  the 
reports  to  be  prepared  from  the  collected  data,  and  to 
invoke  the  preparation  of  reports.  It  requires  the  following 
functions : 

1.  automatic  entry  of  data  into  reporting  forms, 

2.  automatic  generation  of  files  from  which  records 
and  reports  are  generated, 

3.  capability  to  alter  report  formats, 

4.  capability  to  alter  rules  for  file  building  and 
report  generation, 

5.  algorithms  for  automated  statistical  analysis,  and 

6.  information-flow  management  of  work-in-progress. 

This  enhancement  would  be  effected  by  technical  con¬ 
trollers  by  using  two  related  but  different  modes  of  opera¬ 
tion  -  a  setup  mode  and  an  operate  mode.  During  the  setup 
mode,  the  operator  (a  programmer  or  perhaps  even  a  technical 
controller)  would  establish  the  basic  parameters  to  control 
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rule-making  and  file  manipulation.  The  operate  mode  would 
then  allow  the  technical  controller  to  use  and  even  modify 
those  pre-established  parameters  to  actually  generate 
records  and  reports. 

The  dialogue  expected  between  the  operator/technical 
controller  and  the  machine  is  visualized  to  be  similar  to 
those  type  commands  normally  utilized  for  file  management, 
text  editing,  and  data  manipulation  at  an  on-line  inter¬ 
active  terminal  in  a  time-shared  environment,  rather  than 
a  traditional  high  order  language  for  computer  programming. 

The  main  thrust  of  this  thesis  is  to  develop  represen¬ 
tative  programs  which  will  facilitate  the  required  functions 
of  this  enhancement.  The  next  chapter  describes  the  rudi¬ 
mentary  features  of  a  candidate  ATEC  language  for  this  auto¬ 
matic  report  generation  enhancement. 
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V.  RULE-DIRECTED  INTERACTIVE  TRANSACTION  AGENT  (RITA) 

This  chapter  will  describe  an  innovative  approach  to 
computer  programming,  termed  production  rule  systems  and 
in  particular  the  RITA  system.  Because  of  the  unique  fea¬ 
tures  of  RITA,  it  offers  a  potential  software  solution  to 
the  ATEC  data  management  requirement. 

A.  PRODUCTION  RULE  SYSTEMS 

Typical  computer  software  programs  operate  in  a  pre¬ 
determined,  fixed  sequence  process,  knowing  which  coded 
commands  are  to  be  next  executed  in  the  program.  This 
class  of  programs  has  been  of  tremendous  utility  to  a  wide 
range  of  users.  However,  for  certain  applications  a  differ¬ 
ent  approach  in  program  control  is  needed,  i.e.,  quite 
often  it  is  desirable  to  have  the  data  base  contents 
determine  the  program  execution.  Thus  was  born  the 
development  of  production  rule  systems. 

A  production  rule  system  is  a  program  comprised  of  a 
set  of  statements  or  rules  which  are  of  the  following  form: 
if  a  particular  condition  exists,  then  perform  a  certain 
action.  Conventional  shorthand  notation  for  the  production 
rule  form  is  condition  -*•  action.  The  condition  is  a  state¬ 
ment  (s)  about  the  contents  of  the  data  base.  The  action 
is  a  process (es)  which  is  performed  upon  the  contents  of 
the  data  base.  The  rules  operate  upon  the  data  base  under 
the  control  of  a  monitor  which  interprets  the  rules. 
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When  the  program  is  executed,  the  data  base  is  checked 
by  the  production  rule  system  to  determine  if  the  first  rule 
condition (s)  is  true.  If  it  is  found  to  be  true,  then 
the  associated  action (s)  is  performed  upon  the  data  base. 

After  the  rule  has  successfully  "fired"  or  if  the  rule 
condition (s)  is  not  true,  the  next  rule  is  similarly  checked. 
This  process  of  checking  the  rule  condition (s)  and  performing 
the  action (s)  is  recycled  continuously  until  all  rules  are 
found  to  be  false  or  a  special  halting  function  is  encoun¬ 
tered.  In  this  manner,  the  production  rules  cause  the  pro¬ 
gram  execution  to  be  dependent  upon  the  contents  of  a  con¬ 
tinuously  modified  data  base. 

The  conventional  production  rule  systems  described  above 
are  termed  condition-driven  since  the  rules  make  contact 
with  the  data  base  through  the  rule  conditions.  Another 
class  of  production  rule  systems  interact  with  the  data  bp.se 
through  the  rule  actions,  and  thus  are  termed  action -driven. 
This  second  class  of  systems  attempt  to  prove  the  action  by 
first  checking  for  it  directly  in  the  data  base  or  failing 
in  that,  by  showing  that  the  associated  conditions  are 
true,  in  a  deductive  inference  fashion  [12] . 

A  number  of  different  applications  have  used  either  the 
condition-driven  or  action-driven  systems.  The  next  section, 
however,  will  present  a  unique  development  which  utilizes 
both  condition-  and  action-driven  production  rule  systems. 
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B.  DEVELOPMENT  OF  RITA 

RITA  is  an  acronym  which  originally  stood  for  Rand 
Intelligent  Terminal  Agent  but  now  has  come  to  be  know  as 
Rule-directed  Interactive  Transaction  Agent.  The  RITA 
system  was  designed  and  implemented  in  the  mid-1970's  by 
the  Information  Sciences  Department  of  Rand  Corporation 
under  development  contract  from  the  Information  Processing 
Techniques  Office  of  the  Advanced  Research  Projects  Agency 
(ARPA)  of  the  DoD.  RITA  is  intended  to  serve  as  a  stand¬ 
alone  resource  for  the  purposes  of  text  manipulation,  routine 
interaction  with  local  and  remote  information/computing 
systems  and  networks,  or  even  development  of  heuristic 
models  to  aid  in  decision-making  and  analysis  [8,9]. 

The  design  philosophy  of  RITA  is  based  upon  the  following 
premises : 

1.  Future  users  of  computer  systems  will  tend  to  be 
from  outside  the  realm  of  "computer  sophisticates".  These 
users  will  need  computer  systems  designed  to  their  level 
of  expertise. 

2.  Microprocessor  technology  advances  are  projected 
to  make  available  in  the  mid-1980's  interactive,  intelli¬ 
gent  terminals  which  have  the  processing  capability  of 
today ' s  minicomputers . 

3.  This  user  terminal  should  have  sufficient  data 
storage  and  handling  capability  to  allow  stand-alone  opera¬ 
tion,  immediacy  of  response,  and  textual  editing  and 
retrieval. 
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4.  The  agent  must  provide  two-way  communications  with 
external  computer  systems  and  with  the  user,  especially  in 
explaining  its  behavior  to  the  user. 

5.  The  agent  must  maintain  a  catalogue  of  assigned 
tasks,  schedules,  and  deadlines  which  are  protected  during 
system  downtime  and  managed  according  to  its  own  calendar 
and  clock  time  functions. 

The  RITA  system  is  a  collection  of  computer  programs 
designed  to  facilitate  the  writing  of-  user  application  pro¬ 
grams,  called  user  agents,  which  provide  the  user  with  an 
intelligent  interface  with  the  external  computer  system. 

The  RITA  programs  are  written  in  the  C  language,  with  a 
few  small  subroutines  written  in  assembly.  The  present 
RITA  Version  2.0  runs  under  the  UNIX  Version  6  operating 
system,  with  Rand  modifications,  and  often  makes  use  of 
many  of  the  UNIX  system  capabilities.  RITA  has  been  human- 
engineered  to  the  extent  that  the  user  agents  can  be  written 
in  near-English  language  [9] . 

The  RITA  system  is  very  large  and  depends  upon  the  use 
of  separate  instruction  and  data  registers  if  a  minicomputer, 
such  as  the  Digital  Equipment  Corporation  PDP  11/45  or 
11/70  presently  in-service  at  Rand,  is  used.  The  current 
Rand  system  can  accommodate  approximately  280  kbytes  of 
program  and  data  storage  in  core.  This  capacity  would  be 
equivalent  to  about  120  rules  operating  upon  a  data  base 
of  130  objects.  It  is  this  instruction  set  and  data  base 
that  will  eventually  be  able  to  reside  in  future  intelligent 
terminals  [9]. 


The  RITA  system  software  is  available  to  government 
contractors  and  agencies  and  private  organizations  for  a 
modest  charge  to  cover  tape  and  machine  costs  at  Rand. 

Rand  retains  a  corporation  official  to  serve  as  the  RITA 
Interface  (RIF)  to  discuss  matters  of  distribution,  documen¬ 
tation,  bugs,  etc.  Bolt  Beranek  and  Newman  (BBN)  is  respon¬ 
sible  for  maintaining  the  RITA  system  (based  on  UNIX)  within 
the  context  of  the  ARPA  program.  A  number  of  computer  cen¬ 
ters  maintain  the  RITA  system  on-line,  while  others  have 
the  distribution  tapes  on  hand  [10]. 

C.  UTILIZATION  OF  RITA 

Learning  the  proper  commands,  processes,  syntax,  and 
unique  features  of  RITA  is  a  special  study  in  itself.  The 
reader  is  referred  to  the  source  documents  listed  in  the 
bibliography  for  a  detailed  study  of  RITA  [8,11].  The 
following  description  is  offered  as  only  a  rudimentary 
overview. 

A  RITA  program  is  a  set  of  commands  along  with  a  collec¬ 
tion  of  rules  and/or  goals  which  can  be  tested  and  which 
direct  certain  actions  if  the  rule  premises  are  true.  The 
data  which  are  generated  or  acted  upon  are  stored  in  the 
form  of  objects.  The  data  base  consists  of  a  collection 
of  object-attribute-value  triples. 

RITA  is  usually  run  in  an  interactive  mode  during  the 
creation  of  the  rule-sets  and  initialization  of  the  data 
objects.  As  the  user  creates  objects  and  rules,  RITA  checks 
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them  for  syntax  errors  and  then  stores  the  input.  There 
can  be  considerable  dialogue  between  the  user  and  RITA 
during  the  course  of  creating,  viewing,  and  storing  these 
items.  RITA  types  an  asterisk  (*)  to  the  user  whenever  it 
is  ready  to  receive  more  input.  All  input  must  be  terminated 
by  a  semicolon  (;)  and  carriage  return. 

The  user  can  invoke  the  RITA  program  to  run  and  thus 
test  all  entered  rules ,  executing  those  with  true  premises . 
Further,  all  entered  rules  and  data  can  be  stored  for  subse¬ 
quent  recall  and  utilization.  RITA  can  operate  either  with 
input  from  the  user  or  from  previously  stored  files  without 
further  human  intervention. 

RITA  objects  are  stored  in  the  form  of  an  object  class 
or  type  which  has  an  arbitrary  number  of  attributes,  each 
of  which  has  an  assigned  value.  These  object-attribute-value 
triples  are  operated  upon  by  the  rule  sets;  their  ability 
to  be  readily  changed  in  attribute  and  value  gives  the  RITA 
process  its  dynamic  nature.  Thus,  the  content  of  the  data 
base  can  have  just  as  profound  affect  on  the  program  output 
as  the  rules  and  commands.  An  example  of  a  RITA  object  is: 

*object  horse 

color  is  "grey", 
age  is  "7", 

owner  is  ( "linda" , "mark" ) ; 

A  RITA  command  may  be  either  a  rule  or  goal ,  an  action 
by  itself,  or  a  directive  to  the  system. 

RITA  rules  are  the  condition-action  rule  sets  discussed 
earlier.  The  "if"  part  of  a  rule  consists  of  any  number  of 
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premises,  all  of  which  must  be  true  in  order  for  the  rule 
to  "fire".  The  premises  test  various  attributes  of  the 
data  base  (the  objects) ,  and  the  resulting  actions  can 
then  modify  the  data  base.  The  actions  can  also  have  affect 
on  other  systems  external  to  RITA,  such  as  the  UNIX  data 
base  or  certain  ARPANET  processes.  An  example  of  a  RITA 
rule  is: 

*rule  airforce 

if  the  service  of  the  man  is  "USAF" 

then  create  a  uniform  whose  color  is  "blue"; 

A  RITA  rule  will  continue  to  "fire"  until  either  the 
premises  are  no  longer  true  or  a  special  halting  function 
is  encountered.  The  halting  function  is  used  by  inserting 
as  the  last  action  in  a  rule  the  phrase,  "and  return  success;". 
This  causes  not  only  the  program  to  halt  but  to  also  print 
out  to  the  user,  "Success!",  at  the  end  of  the  program  output. 

RITA  goals  are  special  kinds  of  rules  used  in  deductions. 
With  few  exceptions,  all  premises  which  can  be  used  for  rules 
can  be  used  for  goals.  When  a  goal  is  executed,  the  one 
relevant  action  clause  is  "fired"  which  chains  it  to  the 
deduction.  An  example  is: 

*goal  graduation 

if  the  thesis  of  the  student  if  "complete" 

then  set  the  status  of  the  wife  to  "glad"; 

When  a  RITA  deduce  command  is  enacted,  RITA  first 
searches  all  goals  to  find  the  appropriate  action  which 
would  yield  the  desired  result.  Then  the  selected  goal  is 
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tested  for  whether  the  premises  are  true.  This  process 
usually  leads  to  testing  other  goals  in  a  "backward  chaining 
process"  until  a  true  premise  is  discovered. 

RITA  commands  can  perform  several  other  actions  on 
the  data  base,  such  as  replace  or  remove  values,  send  data 
to  another  data  base,  print  specified  objects  and/or 
rules,  and  load  additional  files.  RITA  directives  issue 
orders  to  the  RITA  system,  such  as  run  a  program,  debug 
a  program,  establish  a  temporary  access  to  UNIX,  and  exit 
the  program. 

RITA  also  contains  several  built-in  functions  to  ease 
the  desired  processing  of  data,  comparable  to  simplified 
subroutines.  Further,  fundamental  arithmetic  operations 
can  be  called  up  by  use  of  the  following  symbols:  +  -  /  *  . 

The  UNIX  operating  system  provides  a  pipe  capability 
which  RITA  can  use  to  establish  communications  channels, 
called  UNIX  ports,  with  external  systems.  This  capability 
allows  RITA  to  send/receive  messages  to/from  the  user  or 
itself.  Further,  it  enables  a  computer- to-computer  link 
with  external  systems  using  ARPANET  procedures. 

This  concludes  the  description  of  RITA.  The  next 
chapter  shows  a  representative  RITA  agent  -  rules,  objects, 
and  commands  -  that  could  be  used  to  implement  the  ATEC 
automatic  report  generator  enhancement. 
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VI.  RITA  AGENT  FOR  ATEC 


This  chapter  presents  in  a  sequential  fashion,  a 
methodology  that  could  be  used  to  program  a  RITA  agent  for 
producing  the  ATEC  automatic  report  generator.  The  agent  was 
built  piece-meal,  adding  on  rules  incrementally  to  demonstrate 
the  fundamental  requirements  of  the  ATEC  enhancement. 


A.  A  REPORT  FORMAT 

The  format  for  a  report,  which  could  be  established  by 
the  set-up  technical  controller,  used  a  single  rule  which 
queried  the  user,  or  operating  technical  controller,  for 
certain  data  values.  These  values  were  then  assigned  to 
certain  attributes  and  the  resulting  report  with  data  value 
entries  were  displayed  to  the  operator. 

The  rule  for  doing  this  was: 
rule  report 

if  status  of  report  is  "due" 

then  set  the  name  of  report  to  "Trouble  Ticket" 
and  send  "What  is  the  CCSD?"  to  user 

and  receive  next  {anything  'ccsd'  followed  by  from  user 

and  set  ccsd  of  report  to  'ccsd' 

and  send  "What  is  the  source  of  the  report?"  to  user 
and  receive  next  {anything  'source'  followed  by  "~j" }  from 
user 

and  set  source  of  report  to  'source' 
and  send  "What  is  circuit  priority?"  to  user 
and  receive  next  {anything  'priority'  followed  by  "~j"}  from 
user 

and  set  priority  of  report  to  'priority' 
and  send  "What  is  your  station?"  to  user 

and  receive  next  {anything  'station'  followed  by  "~j"}  from 
user 

and  set  station  of  report  to  'station' 

and  send  "Is  the  circuit  send  or  receive?"  to  user 

and  receive  next  {anything  'snd/rcv'  followed  by  "~j"}  from 


and  set  snd/rcv  of  report  to  'send/rcv' 

and  send  "Enter  the  date-time-group  of  the  outage,  in  the 
form  (last  digit  of  calendar  year,  julian  date,  zulu 
time)."  to  user 

and  receive  next  (anything  'dtg-out'  followed  by  ",'j"}  from 
user 

and  set  dtg-out  of  report  to  'dtg-out' 

and  send  "Enter  the  date-time-group  of  restoral ,  in  the  form 
(last  digit  of  calendar  year,  julian  date,  zulu  time." 
to  user 

and  receive  next  (anything  'dtg-in*  followed  by  " ~ j " }  from 
user 

and  set  dtg-in  of  report  to  'dtg-in' 

and  send  "What  is  the  code  for  the  reason  for  outage?"  to 
user 

and  receive  next  anything  'rfo-code'  followed  by  "  j"  from 
user 

and  set  rfo-code  of  report  to  'rfo-code' 

and  send  "Enter  any  desired  remarks,  limited  to  one  line." 
to  user 

and  receive  next  (anything  'remarks'  followed  by  "~j"}  from 
user 

and  set  remarks  of  report  to  ' remarks ' 
and  send  concat  ( "  ~  j  ~  j  ~  j-'  j  ~  j  "  )  to  user 
and  display  object  report 
and  set  status  of  report  to  "not-due" 
and  set  status  of  techcon  to  "working4" 
and  return  success; 

As  each  question  was  sent  to  the  user,  the  program  stopped 

until  the  response  was  typed  at  the  keyboard.  A  typical 

output  from  running  this  rule  was  a  trouble  ticket  report 

as  follows; 

What  is  the  CCSD? 

JJAV9ABC 

What  is  the  source  of  the  report? 

Maintenance  section 
What  is  circuit  priority? 

02 

What  is  your  station? 

MRE 

Is  the  circuit  send  or  receive? 
send 

Enter  the  date-time-group  of  the  outage,  in  the  form  (last 
digit  of  calendar  year,  julian  date,  zulu  time). 
(8,345,2100) 

Enter  the  date-time-group  of  restoral,  in  the  form  (Last  digit 
of  calendar  year,  julian  date,  zulu  time) . 

(9,346,1545) 

What  is  the  code  for  the  reason  for  outage? 

23 

Enter  any  desired  remarks,  limited  to  one  line. 

Bad  resistor  located  in  transmitter  and  is  now  on  order. 
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OBJECT  report<l>: 


status 

IS 

"due" , 

name 

IS 

"Trouble  Ticket", 

ccsd 

IS 

"JJAV9ABC" , 

source 

IS 

"Maintenance  section", 

prior  cy 

IS 

"02"  , 

station 

IS 

" MRE " , 

snd/rcv 

IS 

"send"  , 

dtg-out 

IS 

"(8,345,2100)", 

dtg-in 

IS 

"  (9,346,1545) ", 

rf o-code 

IS 

"23"  , 

remarks 

IS 

"Bad  resistor  located  in  transmitter 

and  is  now  on  order."; 


Repeated  running  of  the  rule  creates  additional  versions 

of  the  object  "report"  which  are  distinguished  by  local 

labels  assigned  automatically  by  RITA.  These  object  names 

would  be  of  the  form: 

OBJECT  report<l> 

OBJECT  report<2> 


OBJECT  report<n> 

where  n  is  the  number  of  repeated  runnings  of  the  rule. 

The  format  of  the  printout  was  that  typically  encountered 
when  displaying  an  object.  If  a  different  format  were 
desired,  then  a  special  "display  concat"  command  could  have 
been  devised.  One  such  version  and  the  resulting  printout 
was : 

and  display  concat ( "CCSD:  ",ccsd  of  report, 

~jSource:  ",  source  of  report,  "''j  Priority:  ", 

priority  of  report,  "‘'j  Snd/rcv:  ", 

snd/rcv  of  report ," ~jDTG-OUT :  ",dtg-out  of  report, ’"'j 
DTG-IN :  ",dtg-in  of  report , "  A  j RFO  Code:  ",rfo-code 

of  report, "Aj Remarks :  ",  remarks  of  report 

"~j~j~j~j")  and  return  success; 
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TROUBLE  TICKET 


CCSD :  JJAV9ABC 

Source:  Maintenance  section 

Priority:  02 

Station:  MRE 

Snd/rcv:  send 

DTG-OUT:  (9,345,2100) 

DTG-IN :  (9,346,1545) 

RFO  Code:  23 

Remarks:  Bad  resistor  located  in  transmitter  and  is  now 

on  order. 

Unfortunately,  it  was  not  possible  to  store  and  then  manipulate 
this  printout  as  a  RITA  object.  Creating  a  printout  format 
different  than  that  produced  by  RITA  for  an  object  was  quite 
undesirable.  Only  RITA  objects  were  used  for  report  printouts 
in  the  remainder  of  this  program. 

B.  CHANGING  REPORT  ENTRIES 

There  were  several  options  available  to  the  user  to 
modify  report  entries.  One  way  was  to  revise  the  basic  rule 
itself,  using  normal  UNIX  text  editing  procedures,  and 
change  the  content  of  the  questions.  Another  was  to  rearrange 
the  order  of  the  send  and  receive  action  pairs  to  revise  the 
sequence  of  the  attributes  in  the  printout. 

If  only  changes  in  values  were  desired,  the  user  could 
have  deleted  the  object  report  and  run  the  rule  again.  Or 
individual  value  entries  could  have  been  changed  by  substi¬ 
tuting  another  value  using  a  command  such  as: 

*set  the  ccsd  of  the  report  to  "xxxxxxxx"; 
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C.  STORING  AND  DELETING  THE  REPORT 

Storing  a  RITA  object  was  quite  straight-forward.  The 
simple  command  which  follows  would  store  the  report  in  a 
UNIX  file  named  "trubltik": 

*display  object  report  to  file  trubltik; 

The  external  UNIX  files  could  be  examined  to  verify  that 
the  report  had  indeed  been  stored  by  entering, 

*shell ; 

%ls 

%cat  trubltik 

The  "shell"  command  caused  RITA  to  temporarily  leave  the 
RITA  mode  and  enter  UNIX.  The  "Is"  and  "cat  trubltik" 
commands  caused,  respectively,  the  index  of  all  UNIX  files 
and  the  contents  of  file  "trubltik"  to  be  displayed  to  the 
user . 

This  new  file,  "trubltik",  was  then  permanently  filed 
until  it  was  purposely  removed  from  the  UNIX  external  files. 
There  were  two  methods  for  removing  UNIX  Files.  One  method 
used  the  universal  UNIX  command, 

%rm  trubltik 

The  other  method  was  a  Rand  developed  procedure  which 
used  the  special  UNIX  command, 

%del  trubltik 
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This  second  form  was  preferred  since  before  removing 
the  file  it  repeated  the  filename  to  be  deleted  and  then 
asked  the  user  to  verify  that  the  file  was  actually  to  be 
removed.  Thus,  two  positive  actions  were  required  to  delete 
a  file,  whose  inadvertent  deletion  could  possibly  have  been 
disastrous . 


D.  SENDING  A  REPORT 

In  order  for  RITA  to  send  information  outside  of  itself, 

it  had  to  activate  a  communications  link,  called  a  UNIX  port, 

to  the  external  location.  Several  protocols  needed  to  be 

established  with  the  distant  computer  facility  to  verify  the 

user,  password,  and  account,  as  well  as  to  transfer  the  file 

and  to  coordinate  end  of  transfer  and  disconnect. 

The  basic  provisions  of  the  ARPANET  File  Transfer 

Protocol  (FTP)  satisfied  the  above  requirements.  The 

following  program  established  the  link,  displayed  its 

progress,  printed  the  index  of  filenames  at  the  remote 

location  before  and  after  the  file  was  transferred  to  the 

distant  computer,  and  then  disestablished  the  link. 

object  send. report: 
state  is  "start"; 

object  portl:; 

rule  ftp: 

if:  the  state  of  send. report  is  "start" 
then:  send  concat  ( " ftp"  ,  to  portl 

and  receive  next  ("Host:"  followed  by  anything}  for  15  seconds 

from  portl  as  the  response  of  port  1 

and  set  state  of  send. report  to  "sendhostname" ; 
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rule  sendhostname : 

if:  the  state  of  send. report  is  "sendhostname" 
and  the  response  of  portl  is  known 

then:  send  concat ( " isia" ,  "~j")  to  portl  and  receive  next 
{anything  followed  by 

"Connections  established"  followed  by  anything}  for  15  seconds 

from  portl  as  the  response  of  portl 

and  display  concat  response  of  portl) 

and  set  state  of  send. report  to  "senduser"; 

rule  senduser: 

if:  the  state  of  send. report  is  "senduser"  and 
the  response  of  portl  is  known 

then  send  concatC'user  nps-accat",  to  portl 

and  receive  next  {anything  followed  by  "User  name  accepted" 
followed  by  anything}  for  15  seconds  from  portl  as  response 
of  port  1 

and  set  state  of  send. report  to  "sendpass"; 
rule  sendpass: 

if:  the  state  of  send. report  is  "sendpass" 
and  the  response  of  portl  is  known 
then  send  concat ( "pass" ,  "~j")  to  portl 

and  receive  next  {"Password:"}  for  15  seconds  from  portl 
as  response  of  port  1 

and  set  state  of  send. report  to  "sendpassword" ; 
rule  sendpassword: 

if  the  state  of  send. report  is  "sendpassword" 
and  the  response  of  portl  is  known 
then  send  concat  {  "c77 "  ,  "/'j" )  to  portl 

and  receive  next  {anything  followed  by  "Login  completed" 
followed  by  anything}  for  15  seconds  from  portl  as  response 
of  portl 

and  display  concat ( ”~j ” ,  response  of  portl,  " ~  j  ~  j " ) 
and  set  state  of  send. report  to  "sendacct"; 

rule  sendacct: 

if:  the  state  of  send. report  is  "sendacct" 

and  the  response  of  portl  is  known 

then  send  concat ( "acct" ,  "~j")  to  portl 

and  receive  next  {anything  followed  by  "Account  #" 

followed  by  anything}  for  15  seconds  from  portl  as  the 

response  of  portl 

and  set  state  of  send. report  to  "sendacctcode"; 
rule  sendacctcode: 

if:  the  state  of  send. report  is  "sendacctcode" 
and  the  response  of  portl  is  known 
then  send  concat ( "cc-" ,  " ~ j " )  to  portl 

and  receive  next  {anything  followed  by  "Account  command 
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accepted"  followed  by  anything}  for  15  seconds  from  portl 
as  response  of  portl 

and  set  state  of  send. report  to  "logged  in"; 
rule  directoryl: 

if;  the  state  of  send. report  is  "logged  in" 
then;  send  concat ( "status" ,  "  ~j" )  to  portl 

and  receive  next  {anything  followed  by  "NPS-ACCAT"  followed 
by  anything  followed  by  "ARCHIVE"  followed  by  anything} 
for  60  seconds  from  portl  as  the  response  of  portl 
and  display  object  portl 

and  set  the  state  of  send. report  to  "listingl"; 
rule  sendfile; 

if:  the  state  of  send. report  is  "listingl" 
and  the  response  of  portl  is  known 

then:  send  concat  ( "store  trubltik  trubltik",  to  portl 

and  receive  next  {"Transfer  completed"}  from  portl  as 
response  of  portl 

and  display  concat  response  of  portl,  "/'j~j") 

and  set  state  of  send. report  to  "transferred"; 

rule  directory 2: 

if:  the  state  of  send. report  is  "transferred" 
then:  send  concat ( "status" ,  "~j")  to  portl 

and  receive  next  {anything  followed  by  "NPS-ACCAT"  followed 
by  anything  followed  by  "ARCHIVE"  followed  by  anything} 
for  60  seconds  from  portl  as  the  response  of  portl 
and  display  object  portl 

and  set  the  state  of  send. report  to  "listing2"; 
rule  logout: 

if:  the  state  of  send. report  is  "listing2" 
then:  send  concat  ( "bye" ,  "/'j")  to  portl 

and  receive  next  {anything  followed  by  "BYE  command  received" 

followed  by  anything)  from  portl  as  the  response  of  portl 

and  set  state  of  send. report  to  "logged  out" 

and  display  concat  ("~j~j",  response  of  portl,  " /'j"'j") 

and  set  status  of  techcon  to  "working?" 

and  return  success; 


The  output  displayed  to  the  user  during  the  running  of 

this  program  was. 

Unknown  host  name 

Host:  Connections  established"  " 


230  Login  completed 


"OBJECT  portl<l> : 

response  IS  " . 

>  151  <NPS-ACCAT> 

1 51  $XED-MODE-FILE$ . ; 1 
151  TRUBLTIKFILE. ; 1 
1 51 ~vA+] ARCHIVE"; 

II 

-DIRECTORY [ . ; 1 
200  End  of  status. 

>  >  200  Allocation  ignored  on  this  system. 

255  SOCK  3276899858 

250  Store  of  <NPS-ACCAT>TRUBLTIK. ; 1 ;P77 5200 ; ACC- ,  ASCII 
type,  started. 

252  Transfer  completed 

"OBJECT  portl<l> : 

response  IS  ” . 

>  >  151  <NPS-ACCAT> 

151  $XED-MODE-FILE$ . ; 1 
151  TRUBLTIK. ; 1 

151  TRUBLTIKFILE. ; 1 
151  ~v~+] ARCHIVE" ; 


-DIRECTORY [ . ; 1 
200  End  of  status. 

%  %  231  BYE  command  received 

An  operational  disadvantage  of  this  portion  of  the  program 
was  that  security  of  the  system  could  be  compromised  in  the 
process  of  declaring  the  password  and  account  code.  Further, 
additional  program  rules  were  needed  to  accommodate  a  failure 
in  establishing  the  communications  link  or  transferring  the 
data. 

E .  RECEIVING  REPORTS 

The  ATEC  program  is  expected  to  generate  many  reports 
flowing  between  technical  control  facilities,  which  would 
have  to  be  sorted,  catalogued,  stored  and  analyzed.  RITA 
could  provide  this  capability,  receiving  reports  as  they 
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are  generated  and  sent  in  to  the  user  or  by  querying  the 
distant  location  periodically. 

The  next  RITA  program  was  very  similar  to  the  earlier 
one  for  establishing  an  FTP  interconnect.  The  first  seven 
rules  were  essentially  the  same  and  are  omitted  to  save 
space.  The  last  four  rules  were  replaced  with  the  following: 

rule  recvfile 

if  the  state  of  send. reports  is  "logged  in" 
and  the  response  of  port2  is  known 

then  send  concat  ("retrieve  trubltikfile  trubltikf ile" , 
to  port 2 

and  receive  next  {anything  followed  by  "Transfer  completed" 
followed  by  anything}  from  port2  as  response  of  port2 
and  display  concat  response  of  port2) 

and  set  state  of  send. reports  to  "transferred"; 

rule  logouts : 

if:  the  state  of  send. reports  is  "transferred" 
then:  send  concat ( "bye" ,  "Aj")  to  port2 

and  receive  next  {anything  followed  by  "BYE  command  received" 

followed  by  anything}  from  port2  as  the  response  of  port2 

and  set  state  of  send. reports  to  "logged  out" 

and  display  concat  ("^j^j",  response  of  port2, 

and  set  status  of  techcon  to  "working9" 

and  return  success; 

The  output  of  the  program  was  the  following: 


Unknown  host  name 

Host:  Connections  established"  " 

230  Login  completed 


• 

>  255  SOCK  3276899859 

250  ASCII  retrieve  of  < NPS-ACCAT> TRUBLTIKF I LE .; 3  started. 
252  Transfer  completed"  " 


>  >  231  BYE  command  received 
"Success ! 
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This  program  did  nearly  the  same  as  the  earlier  FTP 
program,  except  that  the  file,  " trubltikf ile" ,  was  retrieved 
rather  than  one  being  sent  and  the  new  file  was  not  displayed 
until  the  following  command  was  sent: 

*shell ; 

%cat  trubltikfile 

The  new  file  contained  a  collection  of  trouble  ticket 
reports,  in  an  abbreviated  form  to  conserve  space  and 
modified  to  allow  RITA  mathematical  processing.  Notice  that 
the  second  and  fourth  reports  contain  a  different  CCSD  value 
than  the  others.  It  contained  the  following  reports: 


object  report 

status  is  "due", 

ccsd  is  "JJAV9ABC", 

dtg-in  is  ("9" , "362" , "22" , "15") , 

dtg-out  is  ("9", "361", "09",  "00); 

object  report 

status  is  "due", 

ccsd  is  "GGSD89JK" , 

dtg-in  is  ("9" , "356" , "23" , ”15") , 

dtg-out  is  ("9", "355", "12", "55") ; 

object  report 

status  is  "due", 

ccsd  is " JJAV9ABC" , 

dtg-in  is  ( "9" , "345" , "15" , "00")  , 

dtg-out  is  ("9", "344", "10" ,"10") ; 

object  report 

status  is  "due", 

ccsd  is  "CVFG45JK", 

dtg-in  is  ( "9" , "333" , "18"  ,  " 50" )  , 

dtg-out  is  ("9", "332", "15", "35")  ; 

object  report 

status  is  "due", 

ccsd  is  "JJAV9ABC", 

dtg-in  is  (  "9" , "322" , "03"  ,  "00")  , 

dtg-out  is  ("9", "322", "01", "10"); 
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object  report 

status  is  "due", 

ccsd  is  "JJAV9ABC", 

dtg-in  is  ( "9" , "289" , "20" , "00" ) , 

dtg-out  is  ("9", "279", "21",  "05")  ; 

object  report 

status  is  "due", 

ccsd  is  "JJAV9ABC" , 

dtg-in  is  ( "9" , "267" , "15" , "15 " )  , 

dtg-out  is  ("9", "266", "04", "40") ; 

object  report 

status  is  "due", 

ccsd  is  "JJAV9ABC" , 

dtg-in  is  ("9" , "237" , "23" , ”40" )  , 

dtg-out  is  ("9", "235", "02", "35") ; 

object  report 

status  is  "due", 

ccsd  is  " JJAV9ABC" , 

dtg-in  is  ( "9 " , " 195" , " 01" , "20" ) , 

dtg-out  is  ("9", "194", "20", "55")  ; 

object  report 

status  is  "due", 

ccsd  is  "JJAV9ABC", 

dtg-in  is  ( "9" , "001" , "13" , "40" )  , 

dtg-out  is  ("8" ,"364" ,"18" , "45") ; 


F.  STATISTICAL  ANALYSIS 

The  ATEC  report  generator  enhancement  also  requires  a 
certain  degree  of  statistical  manipulation  of  data  parameters 
The  following  program  demonstrated  RITA'S  capability  in  this 
area,  using  the  "trubltikf ile"  data  base  as  an  example  for 
calculating  the  mean  and  variance  values  for  circuit 
downtimes . 

The  program  first  initialized  the  data  objects  and  then 
screened  through  the  outage  reports  sorting  for  the  desired 
circuit  outages,  in  this  case  for  CCSD  JJAV9ABC.  Set 


ordered  was  specified  in  order  for  the  rules  to  cycle 
individually  through  all  objects  before  the  next  rule  was 
tested. 


object  statistic 
status  is  "compute", 
denominator  is  "0", 
numerator  is  "0", 
summation  is  "0"; 

object  downtime; 

set  ordered; 

rule  statsl 

if  there  is  a  report  whose  status  is  "due" 

and  ccsd  of  report  is  not  " JJAV9ABC" 

then  set  status  of  report  to  "not-applicable" ; 


The  next  set  of  rules  tested  the  values  of  minutes, 
hours,  and  days  in  the  in-  and  out-of-service  date-time- 
groups  and  prepared  those  values  for  a  subtraction  process 


rule  stats2 

if  there  is  a  report  whose  status  is  "due" 

and  member  4  of  dtg-in  of  report  is  less  than  member  4  of 

dtg-out  of  report 

then  put  <member  4  of  dtg-in  of  report  +  60 >  into  dtg-in 
of  report  after  member  3 

and  put  <member  3  of  dtg-in  of  report  -  1>  into  dtg-in  of 
report  after  member  2 

and  remove  member  6  from  dtg-in  of  report 
and  remove  member  4  from  dtg-in  of  report 
and  set  status  of  report  to  "minutes"; 

rule  stats3 

if  there  is  a  report  whose  statis  is  "due" 
then  set  status  of  report  to  "minutes"; 

rule  stats4 

if  there  is  a  report  whose  status  is  "minutes" 

and  member  3  of  dtg-in  of  report  is  less  than  member  3  of 

dtg-out  of  report 

then  put  <member  3  of  dtg-in  of  report  +  24>  into  dtg-in 
of  report  after  member  2 


and  put  <member  2  of  dtg-in  of  report  -  1>  into  dtg-in  of 
report  after  member  1 

and  remove  member  5  from  dtg-in  of  report 
and  remove  member  3  from  dtg-in  of  report 
and  set  status  of  report  to  "hours"; 

rule  stats5 

if  there  is  a  report  whose  status  is  "minutes" 
then  set  status  of  report  to  "hours"; 

rules  stats6 

if  there  is  a  report  whose  status  is  "hours" 

and  member  2  of  dtg-in  of  report  is  less  than  member  2  of 

dtg-out  of  report 

then  put  <member  2  of  dtg-in  of  report  +  365>  into  dtg-in 

of  report  after  member  1 

and  set  status  of  report  to  "days" 

and  remove  member  3  from  dtg-in  of  report; 

rule  stats7 

if  there  is  a  report  whose  status  is  "hours" 
then  set  status  of  report  to  "days"; 


The  next  rule  sets  performed  the  subtractions,  converted 
the  times  to  minutes,  and  performed  the  division  for  deter¬ 
mining  the  mean  of  the  circuit  downtimes  (in  minutes) . 


rule  stats8 

if  there  is  a  report  whose  statis  is  "days" 

then  set  the  downtime  of  report  to  1440  *  <member  2  of  dtg-in 
of  report  -  member  2  of  dtg-out  of  report>  +  60  *  <member  3 
of  dtg-in  of  report  -  member  3  of  dtg-out  of  report>  + 

<member  4  of  dtg-in  of  report  -  member  4  of  dtg-out  of  report> 
and  set  status  of  report  to  "downtime" 

and  put  the  downtime  of  report  into  downtimes  of  statistic; 
rule  stats9 

if  there  is  a  report  whose  status  is  "downtime" 

then  set  the  denominator  of  statistic  to  denominator  of 

statistic  +  1> 

and  set  the  numerator  of  statistic  to  enumerator  of  statistic 
+  downtime  of  report> 

and  set  ccsd  of  downtime  to  ccsd  of  report 
and  set  the  status  of  report  to  "processed"; 


rule  statslO 

if  the  status  of  statistic  is  "compute" 

then  set  the  quotient  of  statistic  to  <numerator  of  statistic/ 
denominator  of  statistic)  > 

and  set  the  status  of  statistic  to  "quotient" ; 


The  next  two  rules  calculated  the  variance  of  the  circuit 
downtimes • 


rule  stats 11 

if  there  is  a  report  whose  status  is  "processed" 

then  set  summation  of  statistic  to  <summation  of  statistic 

+  <<ABS (downtime  of  report  -  quotient  of  statistic) >  * 

<ABS (downtime  of  report  -  quotient  of  statistic) >> 
and  set  status  of  report  to  "finished"; 

rule  statsl2 

if  the  status  of  statistic  is  "quotient" 
then  set  variance  of  downtime  to  concat ( <summation  of 
statistic/denominator  of  statistio,"  minutes  squared") 
and  set  status  of  statistic  to  "variance"; 


At  this  point  it  was  desired  to  compute  the  standard 
deviation  by  taking  the  square  root  of  the  variance. 
Unfortunately,  RITA  did  not  have  a  built-in  function  for 
computing  square  root. 

Then  the  program  converted  the  mean  back  to  days ,  hours , 
and  minutes  and  finally  printed  the  results. 


rule  statsl3 

if  the  status  of  statistic  is  "variance" 
and  quotient  of  statistic  is  less  than  60 

then  set  mean  of  downtime  to  concat (quotient  of  statistic, 
"  minutes") 

and  set  status  of  statistic  to  "computed" 
and  display  object  downtime 
and  set  status  of  techcon  to  "workingll" 
and  return  success; 

rule  statsl4 

if  the  status  of  statistic  is  "variance" 
and  quotient  of  statistic  is  greater  than  60 
and  quotient  of  statistic  is  less  than  1440 
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then  set  mean  of  downtime  to  concat (FLOOR (quotient  of 
statistic/60,"  hours,  ", MOD (quotient  of  statistic , 60) , 
"minutes " ) 

and  set  status  of  statistic  to  "computed" 
and  display  object  downtime 
and  set  status  of  techcon  to  "workingll" 
and  return  success; 

rule  statsl5 

if  the  status  of  statistic  is  "variance" 

and  quotient  of  statistic  is  greater  than  1440 

then  set  days  of  statistic  to  FLOOR (quotient  of  statistic/ 

1440) 

and  set  hours  of  statistic  to  FLOOR (MOD (quotient  of 
statistic, 1440)  /  60) 

and  set  minutes  of  statistic  to  MOD (MOD (quotient  of 
statistic , 1440 ) ,60) 

and  set  mean  of  downtime  to  concat (days  of  statistic,"  days, 

hours  of  statistic,"  hours,  ", minutes  of  statistic , "minutes " ) 

and  set  status  of  statistic  to  "computed" 

and  display  object  downtime 

and  set  status  of  techcon  to  "workingll" 

and  return  success; 

The  program  output  was : 


OBJECT  downtime  1  : 


ccsd 

IS 

"JJAV9ABC" 

i 

variance 

IS 

"18419354. 

686  minutes  squared". 

mean 

IS 

"2  days,  9 

hours,  13.75  minutes"; 

Success ! 

The  next  chapter  presents  another  RITA  agent  which 
operates  in  an  interactive  mode  with  the  user  to  present  all 
the  rules  and  commands  discussed  in  this  chapter. 
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VII.  INTERACTIVE  AGENT 


In  this  chapter  an  interactive,  user-prompting  agent 
is  explained  that  would  allow  the  user  to  execute  the  rules, 
commands,  and  objects  presented  in  the  previous  chapter. 

A.  INTRODUCTION 

The  interactive  routine  explained  in  this  chapter  allowed 
a  terminal  operator  untrained  in  RITA  programming  to  experi¬ 
ence  the  power  and  versatility  of  RITA.  The  routine  con¬ 
sisted  of  a  series  of  rules  that  issued  narrative  explanation 
to  the  user  of  those  keyboard  entries  needed  to  generate  a 
report,  change  format,  send  and  receive  files,  and  obtain 
statistical  data. 

The  operator  input  to  the  agent  was  a  series  of  RITA 
commands  to  load  files  of  data  base  objects  and  rules  and 
to  execute  those  rules.  The  ultimate  output  of  the  agent 
was  the  products  resulting  from  the  rule  executions. 

At  the  time  of  the  writing  of  this  thesis,  the  complete 
program  was  contained  in  the  following  UNIX  filenames: 
demo 

duplicate 
recv. report 
rulereport 
stats 

xmit . report 

which  were  stored  at  host  199,  RAND-UNIX  on  the  ARPANET. 
Readers  who  desire  to  obtain  these  files  should  contact  Dr. 
Gary  Poock  of  the  Naval  Postgraduate  School  (see  distribution 
list  of  the  thesis) . 
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B.  EXPLANATION  OF  AGEN1 


The  first  three  rules  of  the  agent  provided  general 
information  on  the  purpose  of  the  program  and  procedural 
matters.  They  could  have  comprised  a  single  rule  except 
that  there  was  a  RITA  limit  for  the  length  of  a  string  of 
characters  that  could  be  displayed  on  a  user's  terminal, 
rule  one 

if  the  status  of  the  techcon  is  "ready" 
then  send  " -J~J 

This  program  demonstrates  a  capability  for  using  RITA 
programming  techniques  to  produce  an  automatic  report 
generator  enhancement  for  the  ATEC  program.  It  allows  the 
technical  controller  to  perform  the  following  functions: 

A.  Define/generate  data  files  automatically  according 
to  rules  established  by  the  technical  controller, 

B.  Generate/alter  rules  for  building  data  files. 

C.  Generate/alter  report  formats,  and 

D.  Assign  rules  or  mathematical  operations  on  stored 
data."  To  user; 


rule  two 

if  the  status  of  the  techcon  is  "ready" 
then  send  " - J ~  J 

Periodically  during  this  demonstration,  it  will  be 
necessary  for  you  to  enter  certain  commands  at  the  keyboard. 
You  will  be  notified  of  what  to  type.  The  exact  words  will 
be  displayed  and  should  be  typed  in  lower  case  precisely  as 
shown,  without  the  prompt  symbol.  The  carriage  return 
should  be  typed  whenever  the  symbol,  <cr>,  is  shown."  To 
user; 

rule  three 

if  the  status  of  the  techcon  is  "ready" 
then  send  "~J~J 

Should  you  make  a  typing  error,  correct  it  on  the  same 
line  using  the  '#'  key  to  erase  each  erroneous  key  stroke, 
before  you  type  the  carriage  return.  If  you  discover  your 
error  after  typing  the  carriage  return,  then  you  must  start 
the  demonstration  over  from  the  beginning  by  doing  the 
following : 
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A.  While  holding  down  on  the  'Ctrl'  key,  press  the  'esc' 
key.  Then  release  both  keys  and  press  the  carriage  return 
key.  This  should  cause  the  terminal  to  type  out  the  RITA 
prompt  (*) . 

B.  Start  the  demonstration  over  by  typing  the  following 
on  separate  lines  after  receiving  either  the  RITA  prompt 

(*)  or  UNIX  prompt  (%) ,  as  shown  below: 

*exit;  <cr> 

%rita  <cr> 

*load  demo;  <cr> 

*run;  <cr> 

These  same  procedures  shown  above  must  be  followed  in 
the  event  that  either  an  error  or  failure  message  is  displayed 
by  the  terminal."  To  user; 

Rule  four  showed  how  to  temporarily  disconnect  from  RITA 
by  creating  a  UNIX  shell  program  which  displayed  the  inter¬ 
active  rule  that  generated  a  trouble  ticket  report, 
rule  four 

if  the  status  of  the  techcon  is  "ready" 
then  send 

First,  the  demo  will  show  the  set-up  mode  for  creating 
a  report  format.  In  this  case,  a  trouble  ticket  format  is 
prepared  that  will  automatically  receive  value  entries 
specified  by  the  technical  controller.  When  the  RITA  prompt 
(*)  appears,  please  type, 

*shell;  <cr> 

%cat  rulereport  <cr> 

When  the  terminal  stops  typing,  then  hold  down  the  'Ctrl' 
key  while  you  press  the  'd'  key  (once  only)  which  should 
cause  the  RITA  prompt  to  appear.  Then  type  the  following, 

*run;  <cr> 

in  order  for  the  program  to  continue."  To  user 
and  set  the  status  of  techcon  to  "workingl" 
and  return  success; 

Rule  five  explained  how  to  modify  the  report  format 
and  showed  how  to  load  this  report  generator  rule  into 
the  RITA  session.  The  latter  action  also  caused  a  syntax 
error  check  to  be  performed. 
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rule  five 

if  the  status  of  the  techcon  is  "workingl" 
then  send  "AJAJ 

The  above  UNIX  file  is  an  example  of  what  the  set-up 
operator  would  produce  to  create  a  new  report  format.  Normal 
UNIX  text  editing  procedures  could  then  be  used  to  modify 
the  entries  of  format.  Once  the  format  is  finally  decided 
upon,  then  the  file  is  loaded  into  the  RITA  system. 

Loading  a  file  into  the  RITA  system  causes  the  file  to 
be  carefully  checked  to  ensure  that  the  rules  and  objects 
have  been  correctly  written.  Any  errors  will  be  indicated 
for  the  user  to  make  corrections.  Once  all  corrections  have 
been  made  and  the  file  is  again  loaded  into  RITA,  the 
system  will  respond  with  which  rules  and  objects  have  been 
added  (to  this  RITA  session  in  progress)  and  finish  with 
the  RITA  prompt . 

To  see  this  action,  please  type, 

*load  rulereport;  <cr> 

When  the  terminal  stops  typing,  then  type, 

♦run;  <cr> 

in  order  for  the  program  to  continue."  To  user 
and  set  the  status  of  techcon  to  "working2" 
and  return  success; 


Rule  six  enabled  the  user  to  observe  this  report 
generation  rule  in  its  RITA  decompiled  form.  This  form 
resulted  whenever  RITA  stored  statements  were  displayed  to 
the  terminal  using  the  RITA  "display"  command. 


rule  six 

if  the  status  of  the  techcon  is  "working2" 
then  send  " A J A J 

In  order  to  see  this  rule  now  in  a  RITA  format,  type, 
♦display  rule  report;  <cr> 

When  the  terminal  stops  typing,  then  type, 

♦run;  <cr> 

in  order  for  the  program  to  continue."  To  user 
and  set  status  of  techcon  to  "working3" 
and  return  success; 
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Rule  seven  directed  the  user  to  execute  the  rule, 
thus  generating  a  trouble  ticket  report  with  entries  of 
the  user's  choosing. 


rule  seven 

if  the  status  of  the  techcon  is  "working3" 
then  send  "’J'J 

Now  to  see  how  this  rule  functions.  It  will  ask  you, 
the  operating  technical  controller,  certain  questions  to 
determine  the  values  that  are  to  be  entered  into  the  report 
format.  You  may  respond  with  any  values  -  there  are  no 
restrictions  except  that  only  a  single  line  may  be  used, 
and  entries  should  be  completed  with  a  carriage  return. 
Running  the  rule  will  produce  the  report,  which  in  this 
case  is  a  RITA  object,  named  report. 

In  order  for  the  loaded  rule  to  operate,  please  type, 

♦create  a  report  whose  status  is  "due";  <cr> 

♦run; 

When  the  terminal  stops  typing,  type  the  following, 
♦run;  <cr> 

in  order  for  the  program  to  continue."  To  user 
and  set  status  of  techcon  to  "empty" 
and  return  success; 


Rule  eight  explained  how  to  change  entries  after  the 
report  itself  was  produced. 


rule  eight 

if  the  status  of  the  techcon  is  "working4" 
then  send  " " J  ~ J 

If  you  should  desire  to  modify  one  of  the  entries  in 
this  report,  you  could  merely  repeat  the  actions  above, 
with  the  commands, 

♦create  a  report  whose  status  is  "due";  <cr> 

♦run;  <cr> 

However,  an  alternate  method  would  be  to  type  the 
following, 

♦set  the  XXXX  of  the  report  to  "YYYY" ;  <cr> 
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where  XXXX  is  the  attribute,  such  as  CCSD,  find  YYYY  is  the 
new  value.  If  you  desire  to  try  this,  also  type  in, 

♦display  object  report;  <cr> 

in  order  to  verify  that  the  value  has  indeed  been  modified. 
When  the  terminal  stops  typing,  type  in, 

♦run;  <cr> 

in  order  for  the  program  to  continue,"  To  user 
and  set  status  of  techcon  to  "working  5" 
and  return  success; 


Rule  nine  showed  the  simplicity  of  storing  the  report, 
a  RITA  object,  in  the  UNIX  data  files.  It  also  verified 
that  the  report  had  actually  been  stored. 


rule  nine 

if  the  status  of  the  techcon  is  "working5" 
then  send  "*J'J 

Now  would  be  the  time  to  either  store  or  transmit  the 
report,  or  both.  To  store  the  report  in  an  external  (to 
RITA)  UNIX  file,  type, 

♦display  object  report  to  file  trubltik;  <cr> 

where  trubltik  is  the  chosen  filename. 

To  verify  the  file  has  been  stored,  you  must  examine 
the  external  UNIX  files.  The  listing  of  all  UNIX  files 
can  be  viewed  by  typing: 

♦shell;  <cr> 

%ls  <cr> 


You  should  see  your  new  filename  in  the  alphabetical 
listing  of  all  filenames.  You  can  then  verify  the  contents 
of  the  file,  which  should  be  your  trouble  ticket  report, 
by  typing, 

%cat  trubltik  <cr> 

Try  the  above  actions.  When  the  terminal  stops  typing, 
then  hold  down  the  'Ctrl'  key  while  you  press  the  'd'  key 
(once  only)  which  should  cause  the  RITA  prompt  to  appear. 
Then  type  the  following, 
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*run;  <cr> 

in  order  for  the  program  to  continue."  To  user 
and  set  status  of  techcon  to  "working6" 
and  return  success; 

Rule  ten  directed  the  transfer  of  the  report  to  another 
computer  using  the  ARPANET  File  Transfer  Protocol  (FTP) 
procedures.  Rule  ten-a  continued  the  explanation  of  what 
comprised  the  file  transfer  transaction. 


rule  ten 

if  the  status  of  the  techcon  is  "working6" 
then  send  " ~J~J 

In  order  to  send  the  report  to  another  computer,  an 
external  file  must  be  called  in  which  contains  the  various 
protocols  for  establishing  the  communications  links  and 
transferring  the  information.  This  is  all  done  automatically, 
once  the  following  is  typed, 

♦load  xmit. report;  <cr> 

When  the  terminal  response  is  finished  and  the  RITA 
prompt  is  obtained,  then  type, 

*run;  <cr>"  to  user; 


rule  ten-a 

if  the  status  of  techcon  is  "working6" 
then  send  "~J~J 

The  external  file,  named  xmit. report,  establishes  an 
interconnection  with  a  remote  computer  and  causes  a  directory 
of  filenames  stored  at  that  computer  to  be  printed  out.  It 
then  transfers  a  new  file  (trubltik)  to  that  computer  and 
again  causes  the  directory  to  be  printed  out.  Notice  that 
the  trubltik  file  has  been  added.  The  communication  link 
is  then  terminated. 

When  the  typing  has  stopped  at  the  terminal  and  the  RITA 
prompt  is  displayed,  then  type, 

♦run;  <cr> 

in  order  for  the  program  to  continue.  In  the  event  the 
transfer  was  unsuccessful,  you  will  get  a  failure  message 
but  the  program  will  continue."  To  user 
and  set  status  of  techcon  to  "empty" 
and  return  success; 
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Rule  eleven  showed  the  ease  with  which  a  UNIX  data 
file  can  be  deleted  again  creating  a  temporary  UNIX  shell 
program. 


rule  eleven 

if  the  status  of  the  techcon  is  "working7" 
then  send  "~J~J 

Since  reports  contain  perishable  information,  sooner 
or  later  these  stored  reports  need  to  be  removed  from  the 
computer  memory.  All  that  is  necessary  is  to  type  the 
following, 

*shell;  <cr> 

%del  trubltik  <cr> 

The  UNIX  system  will  then  ask  you  to  verify  whether  the 
file  is  actually  to  be  deleted.  Responding  either  'y' 
for  yes  or  'n'  for  no  will  cause  the  file  to  be  deleted  or 
retained,  respectively.  In  this  case,  answer  'y' . 

To  verify  that  the  file,  trubltik,  has  been  deleted, 
we  must  again  examine  the  external  UNIX  files.  The  listing 
of  all  UNIX  filenames  can  be  viewed  again  by  typing, 

%ls  <cr> 


After  perfprming  the  above  actions,  and  when  the 
terminal  has  stopped  typing,  then  hold  down  the  'Ctrl' 
key  while  you  press  the  'd*  key  (only  once)  which  will 
cause  the  RITA  prompt  to  appear.  Then  type, 

*run;  <cr> 

in  order  for  the  program  to  continue"  To  user 
and  set  status  of  techcon  to  "working8" 
and  return  success; 


Rules  twelve  and  thirteen  demonstrated  how  to  use  the 
FTP  procedure  for  retrieving  a  file  of  a  collection  of  outage 
reports  from  a  distant  computer.  In  the  event  the  inter¬ 
computer  connection  was  unsatisfactory,  the  rules  showed 
how  to  obtain  the  file  from  a  duplicate  copy  stored  in 
the  UNIX  data  files. 
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rule  twelve 

if  the  status  of  techcon  is  "working3" 
then  send  "~J*J 

A  special  requirement  of  the  ATEC  program  is  to  receive 
data  from  unique  measuring  equipment  or  remote  computers . 
RITA  can  readily  accommodate  this  need,  using  retrieve 
protocols  similar  to  those  used  earlier  for  transferring 
a  file. 

To  initiate  this  action,  please  type, 

*load  recv. report;  <cr> ; 

When  the  typing  has  stopped  at  the  terminal  and  the 
RITA  prompt  is  displayed,  then  type, 

*run;  <cr> 

./hen  the  terminal  stops  typing  and  the  RITA  prompt  is 
obtained,  please  type, 

*run;  <cr> 

In  order  for  the  program  to  continue."  To  user 
and  set  status  of  techcon  to  "empty" 
and  return  success; 


rule  thirteen 

if  the  status  of  techcon  is  "working9" 
then  send  "~J~J 

When  the  typing  has  stopped  at  the  terminal  and  the 
RITA  prompt  is  shown,  then  type, 

*shell;  <cr> 

%cat  trubltikfile  <cr> 

to  examine  the  contents  of  this  new  file.  Notice  it  is  a 
series  of  trouble  ticket  reports,  in  an  abbreviated  format 
to  save  space  and  slightly  modified  for  RITA  to  perform  the 
mathematical  operations.  In  the  event  that  the  file  was 
not  transferred,  then  you  must  rename  a  duplicate  copy 
stored  in  the  UNIX  files  in  order  for  the  program  to  proceed. 
Please  type, 

%cp  duplicate  trubltikfile  <cr> 

After  the  UNIX  prompt  appears,  hold  down  the  'Ctrl' 
key  while  you  press  the  *d'  key  to  obtain  the  RITA  prompt. 
Then  type, 

*run;  <cr> 

in  order  for  the  program  to  continue."  To  user 
and  set  status  of  techcon  to  "workinglO" 
and  return  success; 


61 


Rule  fourteen  directed  the  execution  of  the  arithmetic 


processing  of  the  collection  of  outage  reports  to  obtain 
statistical  parameters. 


rule  fourteen 

if  the  status  of  techcon  is  "workinglO" 
then  send  "'J^J 

The  next  portion  of  this  demonstration  will  illustrate 
the  use  of  RITA  to  perform  basic  statistical  analysis  of 
data.  We  will  use  the  data  contained  in  the  file, 
trubltikf ile ,  to  calculate  certain  parameters.  Specifically, 
the  mean  and  variance  of  the  circuit  downtime 
will  be  determined  and  displayed.  Please  type, 

*load  stats;  <cr> 

*load  trubltikf ile;  <cr> 

When  the  terminal  finishes  typing  and  the  RITA  prompt 
is  obtained,  type, 

*run;  <cr> 

When  the  typing  is  finished  and  the  RITA  prompt  appears, 
then  type, 

*run;  <cr> 

in  order  for  the  program  to  continue."  To  user 
and  set  status  of  techcon  to  "empty" 
and  return  success; 


Rule  fifteen  merely  advised  of  the  end  of  agent  rules. 


rule  fifteen 

if  the  status  of  techcon  is  "workingll" 
then  send  "~J'J 

This  concludes  the  interactive  demonstration  of  the 
RITA  agent  for  the  ATEC  automatic  report  generator.  In 
order  to  terminate  this  session,  please  hold  down  the  'Ctrl' 
key  while  you  press  the  'd'  key  in  order  to  quit  RITA  and 
return  to  the  UNIX  system.  Then  type  the  following  to 
remove  the  "trubltikf ile"  UNIX  file: 

%rm  trubltikfile 

You  may  now  logout  of  UNIX  or  merely  turn  off  you  terminal." 
To  user 

and  set  status  of  techcon  to  "dead" 
and  return  success; 


C.  ACCESSING  THE  AGENT 


Reference  10  explains  the  RITA  log-in  procedures  in 
tutorial  fashion  in  great  detail  and  should  be  consulted 
by  those  users  not  familiar  with  RITA  or  UNIX. 

After  the  log-in  was  completed,  and  the  UNIX  prompt 
(%)  displayed,  then  the  interactive  agent  was  invoked 
with  the  command: 

%rita  demo 

This  caused  the  interactive  agent  to  be  loaded  and  the 
RITA  prompt  (*)  to  appear.  Then  only  the  following  command 
was  needed  to  activate  the  agent: 

*run; 

From  this  point  on,  the  agent  operated  as  described 
in  the  previous  section. 

An  actual  terminal  printout  of  the  agetn  execution  is 
included  in  Appendix  A. 
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VIII.  CONCLUSIONS 


A .  SUMMARY 

The  RITA  agents  developed  in  this  thesis,  although  not 
operationally  complete,  readily  demonstrated  their  utility 
in  satisfying  the  requirements  of  the  ATEC  automatic  report 
generator  enhancement. 

It  was  observed  that  RITA  was  at  times  quite  slow  at 
processing  rules  and  performing  calculations.  It  is 
assumed  that  processing  time  would  be  improved  using  RITA 
agents  resident  in  microprocessors.  Even  so,  RITA  seemed 
to  be  sufficient  for  ATEC  purposes,  especially  for  small 
station  operations. 

B .  RECOMMENDATIONS 

It  is  suggested  that  further  investigation  be  made  by 
ATEC  program  managers  of  the  potential  for  utilizing  RITA 
in  the  ATEC  program.  The  following  items  require  particu¬ 
lar  attention. 

1.  Specialized  subroutines,  especially  arithmetic/ 
statistical,  should  be  developed  that  would  enhace  the 
ATEC  applications. 

2.  The  procedures  for  FTP  need  to  be  revised  to 
guarantee  operational  security  of  data  as  well  as  user 
password  and  account  code. 

3.  A  methodology  is  needed  for  handling  data  groups 
in  other  than  RITA  object  format. 
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APPENDIX  A 

INTERACTIVE  AGENT  OUTPUT  PRODUCT 


This  appendix  contains  an  actual  terminal  printout 
obtained  from  executing  the  interactive  agent,  "demo," 
described  in  chapter  VII. 


This  program  demonstrates  a  capability  for  using  RITA 
programming  techniques  to  produce  an  automatic  report 
generator  enhancement  for  the  ATEC  program.  It  allows  the 
technical  controller  to  perform  the  following  functions: 

A.  Define/generate  data  files  automatically  according 
to  rules  established  by  the  technical  controller, 

B.  Generate/alter  rules  for  building  data  files, 

C.  Generate/alter  report  formats,  and 

D.  Assign  rules  or  mathematical  operations  on  stored 
data. 

Periodically  during  this  demonstration,  it  will  be 
necessary  for  you  to  enter  certain  commands  at  the  keyboard. 
You  will  be  notified  of  what  to  type.  The  exact  words 
will  be  displayed  and  should  be  typed  in  lower  case  precisely 
as  shown,  without  the  prompt  symbol.  The  carriage  return 
should  be  typed  whenever  the  symbol,  <cr>,  is  shown. 

Should  you  make  a  typing  error,  correct  it  on  the  same 
line  using  the  '#'  key  to  erase  each  erroneous  key  stroke, 
before  you  type  the  carriage  return.  If  you  discover  your 
error  after  typing  the  carriage  return,  then  you  must  start 
the  demonstration  over  from  the  beginning  by  doing  the 
following : 

A.  While  holding  down  on  the  'Ctrl'  key,  press  the 
'esc'  key.  Then  release  both  keys  and  press  the  carriage 
return  key.  This  should  cause  the  terminal  to  type  out 
the  RITA  prompt  (*) . 

B.  Start  the  demons tratio  over  by  typing  the  following 
on  separate  lines  after  receiving  either  the  RITA  prompt 
(*)  or  UNIX  prompt  (%),  as  shown  below: 


<cr> 


*exit;  <cr> 

%rita  <cr> 

*load  demo; 

*run;  <cr> 

These  same  procedures  shown  above  must  be  followed  in 
the  event  that  either  an  error  or  failure  message  is 
displayed  by  the  terminal. 

First,  the  demo  will  show  the  set-up  mode  for  creating 
a  report  format.  In  this  case,  a  trouble  ticket  format  is 
prepared  that  will  automatically  receive  value  entries 
specified  by  the  technical  controller.  When  the  RITA  prompt 
(*)  appears,  please  type, 

*shell;  <cr> 

%cat  rulereport  <cr> 

When  the  terminal  stops  typing,  then  hold  down  the 
'Ctrl'  key  while  you  press  the  'd'  key  (once  only)  which 
should  cause  the  RITA  prompt  to  appear.  Then  type  the 
following , 

*ri.n;  <cr> 

in  order  for  the  program  to  continue. 

Success ! 

*  shell; 

%  cat  rulereport 
rule  report 

if  status  of  report  is  "due" 

then  set  the  name  of  report  to  "Trouble  Ticket" 
and  send  "What  is  the  ccsd?"  to  user 

and  receive  next  (anything  'ccsd'  followed  by  " * J }  from  user 
and  set  ccsd  of  report  to  'ccsd' 

and  send  "What  is  the  source  of  the  report?"  to  user 
and  receive  next  (anything  'source'  followed  by  "•'J''}  from  user 
and  set  source  of  report  to  'source' 
and  send  "What  is  circuit  priority?"  to  user 
and  receive  next  {anything  'priority'  followed  by  "'J" } 
from  user 

and  set  priority  of  report  to  'priority' 
and  send  "What  is  your  station?"  to  user 
and  receive  next  {anything  'station'  followed  by  "~J"} 
from  user 

and  set  station  of  report  to  'station' 
and  send  "Is  the  circuit  send  or  receive?"  to  user 
and  receive  next  {anything  'snd/rcv'  followed  by  "~J"} 
from  user 

and  set  snd/rcv  of  report  to  'snd/rcv' 

and  send  "Enter  the  date-time-group  of  the  outage,  in  the 
form  (last  digit  of  calendar  year,  julian  date,  zulu 
time) . "  to  user 
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and  receive  next  {anything  'dtg-out'  followed  by  "'J"} 
from  user 

and  set  dtg-out  of  report  to  'dtg-out' 

and  send  "Enter  the  date-time-group  of  festoral,  in  the  form 
(last  digit  of  calendar  year,  julian  date,  zulu  time)." 
to  user 

and  receive  next  {anything  'dtg-in'  followed  by  "~J"} 
from  user 

and  set  dtg-in  of  report  to  'dtg-in' 

and  send  "What  is  the  code  for  the  reason  for  outage?" 
to  user 

and  receive  next  {anything  'rfo-code'  followed  by  "~J"} 
from  user 

and  set  rfo-code  of  report  to  'rfo-code' 

and  send  "Enter  any  desired  remarks,  limited  to  one  line." 
to  user 

and  receive  next  {anything  'remarks'  followed  by  ""J"} 
from  user 

and  set  remarks  of  report  to  'remarks' 
and  send  concat ( " ~ J“ J" J~ J~ J" )  to  user 
and  display  object  report 
and  set  status  of  report  to  "not-due" 
and  set  status  of  techcon  to  "working4" 
and  return  success; 

% 

*  run ; 

The  above  UNIX  file  is  an  example  of  what  the  set-up 
operator  would  produce  to  create  a  new  report  format. 

Normal  UNIX  text  editing  procedures  could  then  be  used  to 
modify  the  entries  of  format.  Once  the  format  is  finally 
decided  upon,  then  the  file  is  loaded  into  the  RITA  system. 

Loading  a  file  into  the  RITA  system  causes  the  file  to 
be  carefully  checked  to  ensure  that  the  rules  and  objects 
have  been  correctly  written.  Any  errors  will  be  indicated 
for  the  user  to  make  corrections.  Once  all  corrections  have 
been  made  and  the  file  is  again  loaded  into  RITA,  the 
system  will  respond  with  which  rules  and  objects  have  been 
added  (to  this  RITA  session  in  progress)  and  finish  with 
the  RITA  prompt . 

To  see  this  action,  please  type, 

♦load  rulereport;  <cr> 

When  the  terminal  stops  typing,  then  type, 

♦run;  <cr> 

in  order  for  the  program  to  continue. 

Success ! 
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*  load  rulereport; 
[rule  report  added] 


*  run ; 

In  order  to  see  this  rule  now  in  a  RITA  format,  type, 
*display  rule  report;  <cr> 

When  the  terminal  stops  typing,  then  type, 

*run;  <cr> 

in  order  for  the  program  to  continue. 

Success ! 

*display  rule  report; 
rule  report: 

IF:  the  status  of  the  report  is  "due" 

ThEN:  SET  the  name  of  the  report  to  "trouble  ticket" 

&  SEND  "What  is  the  ccsd?"  to  user 
&  RECEIVE  NEXT  {ANYTHING  'ccsd'  FOLLOWED  BY 

"}  FROM  user 

&  SET  the  ccsd  OF  the  report  TO  ‘ccsd’ 

&  SEND  "What  is  the  source  of  the  report?"  TO  user 
&  RECEIVE  NEXT  {ANYTHING  ’source1  FOLLOWED  BY 


" }  FROM  user 

&  SET  the  source  OF  the  report  TO  ’source’ 

&  SEND  "What  is  circuit  priority?"  TO  user 
&  RECEIVE  NEXT  {ANYTHING  ’priority’  FOLLOWED  BY 


"  }  FROM  user 

&  SET  the  priority  OF  the  report  to  ’priority’ 
&  SEND  "What  is  your  station?"  TO  user 
S.  RECEIVE  NEXT  {ANYTHING  ’station’  FOLLOWED  BY 


"}  FROM  user 

&  SET  the  station  OF  the  report  TO  ’station’ 

&  SEND  "Is  the  circuit  send  or  receive?"  TO  user 
&  RECEIVE  NEXT  {ANYTHING  ’ snd/rcv/  FOLLOWED  BY 


" }  FROM  user 

Sc  SET  the  snd/rcv  OF  the  report  TO  ’snd/rcf’ 

&  SEND  "Enter  the  date-time-group  of  the  outage,  in  the 
form  (last  digit) 


OF  calendar  year,  julian  date,  zulu  time)."  To  user 
&  RECEIVE  NEXT  {ANYTHING  'dtg-out'  FOLLOWED  BY 


" }  FROM  user 

&  SET  the  dtg-out  OF  the  report  TO  'dtg-out' 

&  SEND  "Enter  the  date-time-group  of  restoral,  in  the 
form  (last  digit 

OF  calendar  year,  julian  date,  Zulu  time)."  TO  user 
&  RECEIVE  NEXT  '.ANYTHING  'dtg-in'  FOLLOWED  BY 


"}  FROM  user 

&  SET  the  dtg-in  OF  the  report  TO  'dtg-in' 

&  SEND  "What  is  the  code  for  the  reason  for  outage?" 
TO  user 

&  RECEIVE  NEXT  {ANYTHING  ' rf o-code '  FOLLOWED  BY 


"  }  FROM  user 

&  SET  the  rf o-code  OF  the  report  TO  ' rf o-code ' 

&  SEND  "Enter  any  desired  remarks,  limited  to  one  line." 
TO  user 

&  RECEIVE  NEXT  {ANYTHING  'remarks'  FOLLOWED  BY 


"}  FROM  user 

&  SET  the  remarks  OF  the  report  TO  ‘remarks’ 

&  SEND  concat  " 

"  )  TO  user 

&  DISPLAY  OBJECT  report 

&  SET  the  status  OF  the  report  TO  "not-due" 

&  SET  the  status  OF  the  techcon  TO  "working4" 

Si  RETURN  SUCCESS; 

*  run  ; 

Now  to  see  how  this  rule  functions.  It  will  ask  you, 
the  operating  technical  controller,  certain  questions  to 
determine  the  values  that  are  to  be  entered  into  the  report 
format.  You  may  respond  with  any  values  -  there  are  no 
restrictions  except  that  only  a  single  line  may  be  used, 
and  entries  should  be  completed  with  a  carriage  return. 
Running  the  rule  will  produce  the  report,  which  in  this 
case  is  a  RITA  object,  named  report. 

In  order  for  the  loaded  rule  to  operate,  please  type, 

♦create  a  report  whose  status  is  "due";  <cr> 

*run;  <cr> 
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When  the  terminal  stops  typing,  type  the  following, 

♦run;  <cr> 

in  order  for  the  program  to  continue. 

*  create  a  report  whose  status  is  "due"; 

*  run; 

What  is  the  CCSD? 

JJAV9ABC 

What  is  the  source  of  the  report? 

Maintenance 

What  is  circuit  priority? 

02 

What  is  your  station? 

MRE 

Is  the  circuit  send  or  receive? 

Send 

Enter  the  date-time-group  of  the  outage,  in  the  form  (last 

digit  of  calendar  year,  julian  date,  zulu  time). 

(9,223,1200) 

Enter  the  date-time-group  of  restoral,  in  the  form  (last 

digit  of  calendar  year,  julian  date,  zulu  time). 

(9,224,1345) 

What  is  the  code  for  the  reason  for  outage? 

23 

Enter  any  desired  remarks,  limited  to  one  line. 

Circuit  altrouted  to  BBN78GHF,  parts  are  on  backorder. 

OBJECT  report <1>: 

status  IS 
name  IS 

ccsd  IS 

source  IS 
priority 
station  IS 
snd-rcv  IS 
dtg-out  IS 
dtg-in  IS 
rfo-code 
remarks  IS 


Success ! 

*  run ; 

If  you  should  desire  to  modify  one  of  the  entries  in 
this  report,  you  could  merely  repeat  the  actions  above, 
with  the  commands , 

♦create  a  report  whose  status  is  "due";  <cr> 

♦run;  <cr> 


"due", 

"trouble  ticket", 

"  JJAV9ABC" , 

"maintenance" , 

IS  "02", 

"MRE"  , 

"send", 

" (9,223,1200)  ", 

" (9,224,1345) ", 

IS  "23", 

"Circuit  altrouted  to  BBN78GHF,  parts  are 
on  backorder."; 
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However,  an  alternate  method  would  be  to  type  the 
following, 

*set  the  XXXX  of  the  report  to  "YYYY" ;  <cr> 

where  XXXX  is  the  attribute,  such  as  CCSD,  and  YYYY  is  the 
new  value.  If  you  desire  to  try  this,  also  type  in, 

♦display  object  report;  <cr> 

in  order  to  verify  that  the  value  has  indeed  been  modified. 
When  the  terminal  stops  typing,  type  in, 

♦run;  <cr> 

in  order  for  the  program  to  continue. 

Success ! 


* set  the  ccsd  of  the  report  to  "KLJ897TY"; 


*  display  object  report; 

OBJECT  report<l>: 

status  IS 
name  IS 

ccsd  IS 

source  IS 
priority 
station  IS 
snd/rcv  IS 
dtg-out  IS 
dtg-in  IS 
rfo-code 
remarks  IS 


’not-due" , 

'trouble  ticket", 

'KLJ897TY " , 

’maintenance" , 

IS  "02", 

’MRE" , 

’send", 

'  (9,223,1200) ", 

'  (9,224,1345) ", 

IS  "23", 

'Circuit  Altrouted  to  BBN78GHF ,  parts 
are  on  backorder . " ; 


Now  would  be  the  time  to  either  store  or  transmit  the 
report,  or  both.  To  store  the  report  in  an  external  (to 
RITA)  UNIX  file,  type, 

♦display  object  report  to  file  trubltik;  <cr> 

where  trubltik  is  the  chosen  filename. 

To  verify  the  file  has  been  stored,  you  must  examine 
the  external  UNIX  files.  The  listing  of  all  UNIX  files 
can  be  viewed  by  typing: 

♦shell;  <cr> 

%ls  <cr> 
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You  should  see  your  new  filename  in  the  alphabetical 
listing  of  all  filenames.  You  can  then  verify  the  contents 
of  the  file,  which  should  be  your  trouble  ticket  report, 
by  typing, 

%cat  trubltik  <cr> 

Try  the  above  actions.  When  the  terminal  stops  typing, 
then  hold  down  the  'Ctrl'  key  while  you  press  the  'd'  key 
(once  only)  which  should  cause  the  RITA  prompt  to  appear. 
Then  type  the  following, 

*run;  <cr> 

in  order  for  the  program  to  continue. 

Success ! 

*  display  object  report  to  file  trubltik; 

*  shell; 

%ls 
demo 

duplicate 
recv. report 
rulereport 
stats 
trubltik 
xmit. report 
%cat  trubltik 
OBJECT  report  1  : 

status  IS 
name  IS 

ccsd  IS 

source  IS 
priority 
station  IS 
snd/rcv  IS 
dtg-out  IS 
dtg-in  IS 
rfo-code 
remarks  IS 


% 

*  run ; 

In  order  to  send  the  report  to  another  computer,  an 
external  file  must  be  called  in  which  contains  the  various 
protocols  for  establishing  the  communications  links  and 
transferring  the  information.  This  is  all  done  automatically, 
once  the  following  is  typed, 

*load  xmit. report;  <cr> 


"not-due" , 

"trouble  ticket", 

" KLJ897TY " , 

"maintenance" , 

IS  "02", 

"MRE" , 

"send", 

" (9,223,1200) ", 

" (9,224,1345) ", 

IS  "23", 

"Circuit  altrouted  to  BBN78GHF ,  parts 
are  on  backorder . " ; 
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When  the  terminal  response  is  finished  and  the  RITA 
prompt  is  obtained,  then  type, 

*run;  <cr> 

The  external  file,  named  xmit. report,  establishes  an 
interconnection  with  a  remote  computer  and  causes  a  directory 
of  filenames  stored  at  that  computer  to  be  printed  out.  It 
then  transfers  a  new  file  (trubltik)  to  that  computer  and 
again  causes  the  directory  to  be  printed  out.  Notice  that 
the  trubltik  file  has  been  added.  The  communication  link 
is  then  terminated. 

When  the  typing  has  stopped  at  the  terminal  and  the  RITA 
prompt  is  displayed,  then  type, 

*run;  <cr> 

in  order  for  the  program  to  continue.  In  the  event  the 
transfer  was  unsuccessful,  you  will  get  a  failure  message 
but  the  program  will  continue. 

Success ! 

*  lord  xmit. report; 

[Object  send. report <1 >  added] 

[Object  portl<l>  added] 

[Rule  ftp  added] 

[Rule  sendhostname  added] 

[Rule  senduser  added] 

[Rule  sendpass  added] 

[Rule  sendpassword  added] 

[Rule  sendacct  added] 

[Rule  sendacctcode  added] 

[Rule  directoryl  added] 

[Rule  sendfile  added] 

[Rule  directory 2  added] 

[Rule  logout  added] 

*  run; 

»t 


Unknown  host  name 
Host:  Connections  established"  " 

230  login  completed 

"OBJECT  portl< 1>  : 

response  IS  " . 

>  151  <NPS-ACCAT> 

151  $XED-MODE-FILE$ . ; 1 
151  TRUBLTIKFILE.  ;  3 
151  ”v‘+] ARCHIVE"; 
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-DIRECTORY [ .  ;  1 
200  End  of  status. 

>  >  200  Allocation  ignored  on  this  system. 

255  SOCK  3276899858 

250  store  of  <NPS-ACCAT>TRUBLTIK. ; 1 ; P775200 ; ACC- ,  ASCII  type, 
started. 

252  Transfer  completed 

"OBJECT  portl<l> : 

response  IS  " . 

>  >  151  <NPS-ACCAT> 

151  $XED-MODE-FILE$ . ; 1 
151  TRUBLTIK. ; 1 

151  TRUBLTIKFILE . ; 3 
151  * v~+] ARCHIVE"; 


-DIRECTORY [ . ; 1 
200  End  of  staus. 

>  >  %  %  231  BYE  command  received 

"Success ! 

*  run ; 

Since  reports  contain  perishable  information,  sooner 
or  later  these  stored  reports  need  to  be  removed  from  the 
computer  memory.  All  that  is  necessary  is  to  type  the 
following, 

*shell;  <cr> 

%del  trubltik  <cr> 

The  UNIX  system  will  then  ask  you  to  verify  whether  the 
file  is  actually  to  be  deleted.  Responding  either  ' y' 
for  yes  or  'n'  for  no  will  cause  the  file  to  be  deleted  or 
retained,  respectively.  In  this  case,  answer  'y'. 

To  verify  that  the  file,  trubltik,  has  been  deleted, 
we  must  again  examine  the  external  UNIX  files.  The  listing 
of  all  UNIX  filenames  can  be  viewed  again  by  typing, 

%ls  <cr> 


After  performing  the  above  actions,  and  when  the  terminal 
has  stopped  typing,  then  hold  down  the  'Ctrl'  key  while 
you  press  the  'd'  key  (only  once)  which  will  cause  the 
RITA  prompt  to  appear.  Then  type, 

*run;  <cr> 

in  order  for  the  program  to  continue. 

Success ! 
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*  shell; 

%  del  trubltik 
trubltik 
— delete?  y 
%  Is 
demo 

duplicate 
recv. report 
rulereport 
state 

xmit. report 
% 

*  run; 

A  special  requirement  of  the  ATEC  program  is  to  receive 
data  from  unique  measuring  equipment  or  remote  computers. 
RITA  can  readily  accommodate  this  need,  using  retrieve 
protocols  similar  to  those  used  earlier  for  transferring 
a  file. 

To  initiate  this  action,  please  type, 

*load  recv. report;  <cr>; 

When  the  typing  has  stopped  at  the  terminal  and  the 
RITA  prompt  is  displayed,  then  type, 

*run;  <cr> 

When  the  terminal  stops  typing  and  the  RITA  prompt  is 
obtained,  please  type, 

*run;  <cr> 

in  order  for  the  program  to  continue. 

Success ! 

*  load  recv. report; 

[Object  send. reports<l>added] 

[Object  port]<l>  added] 

[Rule  ftps  added] 

[Rule  sendhostnames  added] 

[Rule  sendusers  added] 

[Rule  sendpasss  added] 

[Rule  sendpasswords  added] 

[Rule  sendaccts  added] 

[Rule  sendacctcodes  added] 

[Rule  recvfile  added] 

[Rule  logouts  added] 


Unknown  host  name 
Host:  Connections  established"  " 

230  login  completed 


>  255  SOCK  3276899859 

250  ASCII  retrieve  of  <NPS-ACCAT>TRUBLTIKFILE. ; 3  started. 
252  transfer  completed"  " 


>  >  231  BYE  command  received 
"Success ! 

*  run; 

When  the  typing  has  stopped  at  the  terminal  and  the 
RITA  prompt  is  shown,  then  type, 

*shell;  <cr> 

%cat  trubltikfile  <cr> 

to  examine  the  contents  of  this  new  file.  Notice  it  is  a 
series  of  trouble  ticket  reports,  in  an  abbreviated  format 
to  save  space  and  slightly  modified  for  RITA  to  perform 
the  mathematical  operations.  In  the  event  that  the  file 
was  not  transferred,  then  you  must  rename  a  duplicate  copy 
stored  in  the  UNIX  files  in  order  for  the  program  to 
proceed.  Please  type, 

%cp  duplicate  trubltikfile  <cr> 

After  the  UNIX  prompt  appears,  hold  down  the  'Ctrl' 
key  while  you  press  the  'd'  key  to  obtain  the  RITA  prompt. 
Then  type, 

*run;  <cr> 

in  order  for  the  program  to  continue. 

Success ! 

*  shell; 

%  cat  trubltikfile 

object  report 

status  is  "due", 

ccsd  is  " JJAV9ABC " , 

dtg-in  is  ("9" , "362" , "22" , "15")  , 

dtg-out  is  ("9", "361", "09", "00") ; 
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object  report 

status  is  "due", 

ccsd  is  "CGSD89JK" , 

dtg-in  is  ( "9" , " 356" , "23" , "15 " ) , 

dtg-out  is  ("9", "355", "12", "55") 

object  report 

status  is  "due", 

ccsd  is  " JJAV9ABC" , 

dtg-in  is  ( "9 " , " 345" , "15" , "00" )  , 

dtg-out  is  ("9" , "344" , "10" , "10") 

object  report 

status  is  "due", 

ccsd  is  "CVFG45JK" , 

dtg-in  is  ("(", "333" , "18" , "50")  , 

dtg-out  is  ("9", "332", "15", "35") 

object  report 

status  is  "due", 

ccsd  is  " JJAV9ABC" , 

dtg-in  is  ("9" , "322" , "03" , "00")  , 

dtg-out  is  ("9", "322" , "01", "10"" 

object  report 

staus  is  "due", 

ccsd  is  " JJAV9ABC" , 

dtg-in  is  ( "9" , "289" , "20 " , "00" )  , 

dtg-out  is  ("9", "279", "21", "05") 

object  report 

status  is  "due", 

ccsd  is  " JJAV9ABC" , 

dtg-in  is  ( "9" , "267" , "15" , "15" )  , 

dtg-out  is  ("9" ,  "266" , "04" ,  "40") 

object  report 

status  is  "due", 

ccsd  is  " JJAV9ABC" , 

dtg-in  is  ("9" , "237" , "23" , "40")  , 

dtg-out  is  ("9", "235", "02", "35") 

object  report 

status  is  "due", 

ccsd  is  " JJAV9ABC" , 

dtg-in  is  ("9" , "195" , "01" , "20" ) , 

dtg-out  is  ("9", "194", "20", "55") 

object  report 
status  is  "due", 
ccsd  is  " JJAV9ABC" , 
dtg-in  is  ("9" , "001" , "13" , "40")  , 
dtg-out  is  ("8", "364", "18", "45") 
% 

*  run; 


77 


The  next  portion  of  this  demonstration  will  illustrate 
the  use  of  RITA  to  perform  basic  statistical  analysis  of 
data.  We  will  use  the  data  contained  in  the  file,  trubltikf ile , 
to  calculate  certain  parameters.  Specifically,  the  mean  and 
variance  of  the  circuit  downtime 
will  be  determined  and  displayed.  Please  type, 

*load  stats;  <cr> 

*load  trubltikf ile;  <cr> 

When  the  terminal  finishes  typing  and  the  RITA  prompt 
is  obtained,  type, 

*run;  <cr> 

When  the  typing  is  finished  and  the  RITA  prompt  appears , 
then  type, 

*run;  <cr> 

in  order  for  the  program  to  continue. 

Success ! 

*  load  stats; 

[Object  statistic<l>  added] 

[Object  downtime<l>  added] 

[Rule  statsl  added] 

[Rule  stats2  added] 

[Rule  stats3  added] 

[Rule  stats4  added] 

[Rule  stats5  added] 

[Rule  stats6  added] 

[Rule  stats7  added] 

[Rule  stats 8  added] 

[Rule  stats9  added] 

[Rule  statslO  added] 

[Rule  statsll  added] 

[Rule  statsl2  added] 

[Rule  statsl3  added] 

[Rule  statsl4  added] 

[Rule  statsl 5  added] 

*  load  trubltikf ile; 

[Object  report<2>  added] 

[Object  report<3>  added] 

[Object  report<4>  added] 

[Object  report<5>  added] 

[Object  report<6>  added] 

[Object  report<7>  added] 

[Object  report<3>  added] 

[Object  report<9>  added] 

[Object  report<10>added] 

[Object  report<ll>added] 
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*  run; 

OBJECT  downtime< 1> : 

ccsd  IS 

variance 
mean  IS 


" JJAV9ABC" , 

IS  "18419354.686  minutes  squared", 
"2  days,  9  hours,  13.75  minutes"; 


Success  I 
*  run ; 

This  concludes  the  interactive  demonstration  of  the 
RITA  agent  for  the  ATEC  automatic  report  generator.  In 
order  to  terminate  this  session,  please  hold  down  the 
'Ctrl'  key  while  you  press  the  '  dr  key  in  order  to  quit 
RITA  and  return  to  the  UNIX  system.  Then  type  the  following 
to  remove  the  " trubltikf ile"  UNIX  file: 

%rm  trubltikfile  <cr> 

You  may  now  logout  of  UNIX  or  merely  turn  off  your  terminal. 
Success ! 


APPENDIX  B 


ARPA 

ATEC 

DCA 

DCS 

FACC 

LRIP 

RITA 

SYSCON 

TCF 


LIST  OF  KEY  ABBREVIATIONS 

Advanced  Research  Projects  Agency 
Automated  Technical  Control 
Defense  Communications  Agency 
Defense  Communications  System 

Ford  Aerospace  and  Communications  Corporation 
Low  Rate  Initial  Production 

Rule-directed  Interactive  Transaction  Agent 

System  Control 

Technical  Control  Facility 
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